Properties of type dynamic within a data class cause compilation to fail
when converting FIR to IR. This is because dynamic types do not have a
proper backing class for symbol lookup. However, dynamic types can just
be considered of type Any for hashCode calculations.
^KT-63094 Fixed
We plan to disable computing full mangled names of declarations in all
manglers except the IR mangler (see the subsequent commits).
From now on, in irText tests we dump only the following mangled names:
- Full mangled names computed using the IR mangler
- Signature mangled names computed using the Descriptor mangler
- Signature mangled names computed using the IR mangler
- Signature mangled names computed using the FIR mangler
Here by a full mangled name we mean the mangled name of a declaration
computed using the `MangleMode.FULL` mode. Those mangled names include
the mangled names of the declaration'a parents.
By a signature mangled name we mean the mangled name of a declaration
computed using the `MangleMode.SIGNATURE` mode.
These mangled names are used to compute an `IdSignature` for
the declaration, hence the name.
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.
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)
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
Before this commit, test data for 'synthesizedDataClassMembers' test
was different between PSI and LT, because we had SYNTHETIC_OFFSET = -2
for synthetic functions and NaiveSourceBasedFileEntryImpl calculated
line/column as 0 for LT. In this commit the dumper was edited to
count -1 as line -1 / column -1 independent of a file entry used.
After this commit there are three different versions of
IR source range tests: classic (K1), FIR/PSI (K2), FIR/LT (K2).
Since 5 tests behave differently for FIR/PSI and FIR/LT,
in this commit their test data was set to FIR/LT state,
so relevant 5 tests are failing for FIR/PSI right now.
They will be fixed in two subsequent commits
Related to KT-59864, KT-60111, KT-59584
For example, `java.util.ArrayList.elementData` is a generic
package-private method. Not unwrapping intersection/substitution fake
overrides resulted in incorrect FQ names being compared in the package
visibility check, which led to the fake override always being created in
any subclass of ArrayList.
This change will help in testing IR fake overrides (KT-61360) because in
the current (temporary) mode, IrFakeOverrideRebuilder throws an
exception if initial fake overrides constructed by fir2ir differ from
the ones rebuilt by the IR -- and here they'll be different after fixing
KT-61366.
Previously fir2ir created real IR properties some getter and setter for
such references, which lead to the situation that there might be a
unbound fake override for synthetic property which wasn't stored in
declaration storage (and code in FakeOverrideGenerator was a hack
to cover this case)
In the same time K1 creates fake property for such cases, which is stored
in IrPropertyReference along with original get... and set... functions
as getter and setter of reference. And in this commit K2 does the same thing
^KT-61637
Brian Norman