Lowering asks whether to generate getter/setter call only when it should
be present. It means the code define explicit getter or setter.
And it seems correct to use it instead of trying direct field access.
The same way as `FirClassUseSiteMemberScope` is present
when there is an implicit receiver with a pure Kotlin type,
`JavaClassMembersEnhancementScope` is present when
the receiver's type comes from Java sources
^KTIJ-26785 Fixed
We shouldn't process other elements (like parameters/receivers) because
we can't modify them anyway. This will help to avoid exceptions like
```
Attempt to load text for binary file which doesn't have a decompiler plugged in
```
in tests
^KT-61431
Otherwise, it will throw exception like:
```
IllegalStateException: No 'FirJvmTypeMapper'
```
Anyway, PsiType is JVM conception, so it is not supposed to be used
outside the JVM platform
^KT-60318
Reporting it for `VIRTUAL_MEMBER_HIDDEN`
is ok, because `VIRTUAL_MEMBER_HIDDEN`
has always been an error, so we are
allowed to treat these as overrides
implicitly.
^KT-59408 Fixed
^KT-59419 Fixed
^KT-57076 Fixed
Originally it was named createModuleFragmentWithSignaturesIfNeeded, because
there was a counterpart `...WithoutSignatures`. Now that function has
gone and there is only one entrypoint left
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
'CodeFragmentCapturedValueAnalyzer' assumes the analyzed code fragment
is then passed to the backend. For property calls, there are several
code generation strategies (field, accessor, delegate). In order to
be able to choose one, the whole property, including its possibly
'const' initializer, must be resolved.
The commit fixes a plenty of 'FirIdeNormalAnalysisSourceModuleCompilerF\
acilityTestGenerated.CodeFragments.Capturing' tests that broke after
the 'FirExpression.type' refactoring.
We should protect return types from value parameters/property accessors
and backing fields from repeatable modifications.
Such declarations can be modified during type resolution by
`transformTypeToArrayType` or property getter type propagation,
so we should be able to restore the original reference in the case of
exceptions (PCE for instance)
^KT-61422
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
This behavior wasn't intended during KT-15470 coding. I only intended to
prohibit `@get:` target on things different from properties. But I
accidentally prohibited `@property` on things different from properties
too
But it's a bug fix anyway, so let's keep it.
I also re-checked the implementation of KT-15470, I don't see any other
unintentional prohibitions
Alexey Merkulov