In case there are Java sources in the module, K2 creates two instances
of `FirModuleDescriptor` with the same name: one for Kotlin sources, one
for Java sources. When building fake overrides in IR, it's important to
understand that those are the same module. Currently it's done by
comparing the names, but in the future it may be improved in KT-62534.
The changed test was in fact unrelated to KT-61805, and the problem
there was rather that no fake override was created for internal property
`schemeState` in `InspectionProfileModifiableModel`.
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.
This leads to type ref referring to generic type variables being
serialized correctly.
When the type variable is declared on the member itself, it's written to
typeParameterName,
otherwise it's written to typeParameter. This is required for
deserialization to work correctly.
#KT-63227 Fixed
Frontend may leak captured types into type arguments, so they should be
approximated before using them in fir2ir cast inserter to determine
a specific type from smartcast
^KT-62863 Fixed
This commit handles situations when some annotation in deserialized code
has an empty array literal argument [] or even non-empty [something].
Before this commit, we tried to guess a type of this array by "resolving"
the relevant annotation class and looking into the corresponding
parameter. Sometimes it can work, but also it can provoke recursive
resolve e.g. when the annotation class is a nested class in the same scope.
In this commit we changed the behavior in the following way:
- first, for non-empty array literals in deserialized code we just
take the array type from the corresponding array literal element
- second, for empty array literals we no more try to "guess" anything.
Instead we approximate array type as Array<Any>, and later at FIR2IR
stage we use the corresponding parameter type instead. At FIR2IR stage,
everything is already resolved and problems with recursions are no more
possible.
#KT-62598 Fixed
Before this commit, we first tried to guess a type of array literal
in deserialized annotation (it's a strange heuristics which can
lead to SOE and maybe not needed at all, see KT-62598, KT-62929),
and then, if unsuccessful, took the type from the first literal element,
if any. Since the second heuristic is much more clear, safe, and
understandable, in this commit they were swapped.
This commit does not fix KT-62598 in general case,
but decreases a set of cases when it can occur to
empty array literals only.
See the commented line at the end of the added test.
Delegated callables in FIR are session-dependant (as fake-overrides),
so it's incorrect to use their FIR as a key for declaration storage.
Pair of original function and owner lookup tag should be used instead
^KT-62671 Fixed
When files from different IrModules are merged in IrActualizer
their IrModule link was not updated. This led to assuming them
as different modules, and incorrect internal visibility handling.
^KT-62623
Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
For reasoning refer to the message of the previous commit
It is the same as for `getIrFunctionSymbol`
There is one failing test here, caused by KT-61941
The issue was here before this commit, but it was hidden
The enumEntriesIntrinsicMultipleEnums.kt test was supposed to check that
JVM backend generates 3 `$EntriesIntrinsicMappings` classes: for X, for
Y, and for Z. Mappings classes are generated for enums without
`entries`, i.e. Kotlin enums compiled without `EnumEntries` language
feature, and Java enums. The test incorrectly _enabled_ the language
feature for X though, and `$EntriesIntrinsicMappings` for X was
generated anyway because of KT-61208.
To keep the original intention of the test, I'm disabling the language
feature for X, so that it will be considered as enum without `entries`.
KT-61208 will be fixed in a separate commit (with separate tests).
The boxInline and bytecodeText tests changed their meaning when language
feature EnumEntries started to be enabled by default, so those changes
are a continuation to ebd43fc8c0. The behavior did not change after
enabling the feature, once again because of KT-61208.
Also, remove obsolete error suppressions which are no longer needed
after 64c8ce18a0.
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
In Kotlin subclasses of `MutableCollection<Int>`, the method
`remove(Int)` has its argument boxed, so that it wouldn't clash with the
method from `java.util.List`. So `JavaOverrideChecker` should understand
that a Java method `boolean remove(java.lang.Integer)` overrides it,
otherwise platform declaration clash was reported.
The code is adapted from `forceSingleValueParameterBoxing` in K1's
`methodSignatureMapping.kt`.
The test has been moved and adapted from diagnostic to codegen box
tests, to check correct backend execution + runtime.
#KT-62316 Fixed
Mikhail Glukhikh