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
#KT-62305 fixed
NB: kotlin reflection do not see script class constructor after
this change, and it's ok, since the fact that the script is compiled
into a class is an implementation detail.
If needed, java reflection could be used to access the constructor.
Mute them for the old JVM backend instead. JVM IR behavior is fine in
all cases except maybe `destructured.kt`, for which there's now an issue
KT-63075.
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)
Mikhail Glukhikh