In some cases we transform flexible type into non-flexible during
enhancement, but don't add `@EnhancedNullability` attribute to them,
which breaks consistency with K1 on IR level
This commit fixes it
^KT-65302
^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
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
Rework rendering of kt-like dump and signatures dump in order to avoid
unstable blank line between declarations of the same level:
1. No blank line for the first declaration inside the member scope of
the class.
2. Always a single blank line between each two subsequent declarations
inside the member scope of the class.
Types based on type parameters which have both hasEnhancedNullability
and hasFlexibleNullability were incorrectly converted to IR: only
`@EnhancedNullability` annotation was added to the IR type. This means
that the nullability of the type started to matter, which is incorrect
because the type is supposed to be flexible.
This backfired in the IR fake override builder mode, where nullability
of methods inherited from both Kotlin maps and Java maps clashed, which
resulted in the exception from FakeOverrideRebuilder.
If the type is both flexible and enhanced, we're now adding
`@FlexibleNullability` to the IR type. Note that `@EnhancedNullability`
is not needed because it only affects primitive types which need to be
handled as wrapper types on JVM, but `@FlexibleNullability` already has
that effect.
IR still slightly differs from K1 for collection subclasses, which can
be seen for example in the changed IR text tests. This is to be
investigated later.
The change in tests is needed because the `kt48495*.kt` tests are now
passing on K2 in the IR fake override builder mode, while failing on the
vanilla K2.
This is related to KT-61370 but does not entirely fix it, although
curiously it fixes all remaining tests which were muted because of it.
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
Code in `ReplaceNumberToCharCallSitesLowering` relies on `Number.toChar`
being declared in IR as non-abstract. Otherwise the
`resolveFakeOverride` call there doesn't work, and the lowering can't
rewrite the call to `toInt().toChar()`, and we end up with a call to the
missing method `Number.toChar` in the bytecode.
#KT-57217 Fixed
In this commit we have a lot of change in test data. This was caused
by the way where we evaluate constants. We split constant evaluation
into two distinct parts: only necessary evaluations for `fir2ir`
(like const val and annotations) and optimizations for lowering.
Now we don't do all constant evaluation on `fir2ir`, but IR
dump is executed after this phase, so test data changed.
#KT-58923
Generating IR declarations for use-site substitution overrides leads
to IR that is different from K1 as well as problems in signature
generation which relies on mangling. Use-site substitutions can contain
references to type parameters from the call-site which aren't handled
in mangling.
#KT-57022 Fixed
This only applies to JVM and fq-names in declaration references
in IR dumps.
This enables us to run more irText tests on platforms other than JVM
(see KT-58605).
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
Otherwise, when we come to `ClassCodegen.kt:173
for `GradleActionTest` and check
`FUN FAKE_OVERRIDE name:<get-project>`,
we then go to `JvmSignatureClashDetector.kt:37`,
and call `mapRawSignature(overriddenFunction)`
which ignores the original `@JvmName`.
It does so because it relies on the property copy
which forgets to copy the getter, but
`@get:JvmName` is stored in it.
Extra when-branches for `FAKE_OVERRIDE` are needed,
because otherwise the annotations would not
be copied in `Fir2IrDeclarationStorage.kt:723`.
Extra when-branches for `DELEGATED_MEMBER` are
needed, because otherwise the generated IR changes
in some tests. For example, see:
`FirLightTreeIrTextTestGenerated.Declarations.testKt35550`.
The `assumesBackingField`-related change is backed by
the `FirLightTreeIrTextTestGenerated.Stubs.testJavaEnum` test.
`this.body = null` ensures the resulting IR
matches K1.
The change in `FirImplicitBodyResolve.kt` is needed,
because otherwise the bootstrap compiler fails at
`:compiler:frontend:compileKotlin`,
but I didn't come up with a smaller test for it.
If we don't make an explicit accessor copy,
then when we later create a `Fir2IrLazyPropertyAccessor`
for the fake override getter, it's `fir` will
be a reference to the `FirProperty`, not `FirPropertyAccessor`.
That's why `DumpIrTreeVisitor` will render `IntrinsicConstEvaluation` as
a getter annotation as well.
`FirPsiIrTextTestGenerated.testDelegatedGenericImplementation`
renders type parameters from `<get-x>`,
because when assigning `extensionReceiverParameter`
of the setter `<set-x>` we come to
`Fir2IrClassifierStorage.kt:638`,
and in this cache there's the parameter with
the `<get-x>` parent.
Note that `typeContext.origin == DEFAULT` in
`getCachedIrTypeParameter`.
It's `DEFAULT` because at the line `Fir2IrDeclarationStorage.kt:335`
the `function` variable is `null` (because there's no setter).
The change in `declarationAttributes.kt` is backed
by the `FirPsiIrTextTestGenerated.testKt45853` test.
^KT-57104 Fixed
^KT-57432 Fixed
Merge-request: KT-MR-9210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
Dmitriy Novozhilov