^KT-61798 Fixed
Review: https://jetbrains.team/p/kt/reviews/14230/timeline
Q: How resolved modality of an accessor affects expect/actual matching
algorithm of properties?
A: It's not expect/actual matching of properties, but expect/actual
matching of properties setter. Declarations (setters in our case) in
actual are allowed to have wider visibility but only if the
appropriate expect is `final`. Before this commit, all property
accessors were always `final` by mistake. After this commit, they
have the modality derived from their containingProperty.
Related problem: PositionStrategy for ACTUAL_WITHOUT_EXPECT can be
improved KT-65720
The fix in `resolveModality` is similar to how `resolveVisibility` works
Related tests:
- ConfigurationCacheForAndroidIT.testKotlinAndroidProject
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testDelegateInterfaceLibrary
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumEntryOverride
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumValueMember
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- DiagnosticCompilerTestFE10TestdataTestGenerated*testChangeSetterVisibilityInOverride
This commit also fixes a missing symbol for KtScriptInitializer
and some symbol pointers
Many tests marked as 'DO_NOT_CHECK_NON_PSI_SYMBOL_RESTORE'
due to KtFirFileSymbol#createPointer logic – the pointer can
be created only for PSI
^KT-61451
^KT-61887
^KT-62626 Fixed
^KT-62693
- An enum entry's body is an initializer with members only accessible
within that body. Because users of the Analysis API might want to
analyze the members of the enum entry initializer, we expose this
initializer via `KtEnumEntrySymbol`. The initializer only exists if
the enum entry has a body.
- We already have some usages of the initializer inside symbol light
classes, which generate a light class for each enum entry, which
includes the enum entry's hidden members.
- To hide the implementation detail that initializers are anonymous
objects, `KtEnumEntryInitializerSymbol` is simply a
`KtSymbolWithMembers`.
- The advantage of making it a `KtSymbolWithMembers`, instead of
providing a custom way to get a member scope, is that we can pass
around the initializer easily, e.g. in `KtEnumEntrySymbolRenderer`.
- We implement `KtEnumEntryInitializerSymbol` directly as a
`KtFirAnonymousObjectSymbol` without a wrapper. This has a few
advantages:
1. We can directly benefit from the anonymous object symbol being a
`KtSymbolWithMembers`, so we don't have to handle enum entry
initializers specially in e.g. `KtFirScopeProvider`.
2. We don't have to implement a new symbol restoration mechanism for
the initializer.
3. This implementation matches the actual FIR tree structure (with a
simplification that the connecting anonymous object expression
between the enum entry and the initializing anonymous object is
omitted).
^KT-61425 fixed
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 prevents `FirConflictsExpressionChecker.kt`
from missing conflicting local functions. It used
to due to inconsistencies in assigning `<local>`,
and this commit makes it a bit more
straightforward.
The change in KtClassTypeQualifierRenderer
prevents `FirOverrideImplementTest.testLocalClass`
from failing in `intellij`. It didn't fail for
callables, because `KtCallableSignatureRenderer`
doesn't try to render packages.
^KT-59186 Fixed
Also, this change adds SinceKotlin and Java.Deprecated to this phase
It fixes some problems with API_NOT_AVAILABLE, so now it is closer to K1
^KT-57648 Fixed
^KT-55723 Fixed
Adds implementation and tests for the new
KtClassOrObjectSymbol.annotationApplicableTargets property on
KtSymbolInfoProvider. This implementation delegates to the canonical
implementation in AnnotationChecker for FE1.0, and to the implementation
in FirAnnotationHelpers for FIR.
This change also includes direct tests for annotationApplicableTargets,
and a fix for FirClassLikeSymbol.getAllowedAnnotationTargets in
FirAnnotationHelpers.
Introduce an extension method to retrieve the set of applicable targets
for an annotation, given the annotation class's symbol.
This extension on `KtSymbolInfoProvider` causes a large amount of churn
in test data files, so this change starts off by introducing the
property and always making it return null. A future change will
introduce the actual behavior change, and will include the testdata
changes for the few tests that actually return useful data for this
property.
- `context(...)` is a modifier that must precede annotations and other
modifiers, so for declarations it is rendered in
`renderAnnotationsAndModifiers`.
- Ignore `@ContextFunctionTypeParams` in the annotation list of FE10
types, as the annotation is an implementation detail of context
receivers in K1 and shouldn't be rendered.
^KT-55098 fixed
Review: https://jetbrains.team/p/kt/reviews/7652
Put this change into a separate commit because:
1. The change is boring and clutters the diff of the first commit
2. The first commits is already too big
Nikita Bobko