This aligns the behavior with K1 and fixes an issue when the default
value was deserialized as FirExpressionStub leading to an exception
in FIR2IR when trying to convert it to an IR expression.
#KT-60120 Fixed
#KT-59610 Fixed
Before this commit, we copied each type parameter during method
enhancement, while not copying the symbol. This led to symbol clashes
in MPP scenarios and various other problems.
Now we create a fully-functional type parameter copy in enhancement
and perform a substitution of old type parameters with new ones
in receiver type, value parameter types, return type,
and type parameter upper bounds.
#KT-59766 Fixed
#KT-59738 Fixed
Supported atomic update of elements for IntArray, LongArray and Array<T>
See KT-58360
Merge-request: KT-MR-11020
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Before this change nodes unification was called if outer call was
completed in the FULL mode, but it may happen even if this call is
actually a part of some other outer call
this error is not valid for scripts, where some receivers are set
later in the lowering, and it looks like in other cases this problem
will be detected later in lowering or codegen anyway.
Earlier we always allowed to interpret `IrGetObjectValue` because
this value is used in const val getter. But now we do a special
check for such getter avoiding visit of `IrGetObjectValue` node.
#KT-59775 Fixed
This fixes an issue with checking for default values in call resolution
(see FirDefaultParametersResolver) where it is expected that the map
only contains a single compatible entry.
#KT-59613 Fixed
... as well as $SwitchMap and other synthetic classes generated by javac
or other JVM language compilers or runtimes.
Note that for Kotlin, all synthetic classes were already handled by the
subsequent check for `KotlinClassHeader.Kind.SYNTHETIC_CLASS`, but after
this change we won't call `ReflectKotlinClass.create` for those, which
is a minor optimization.
#KT-41373 Fixed
... for Kotlin-generated classes which do not correspond to a "class"
from the Kotlin language's point of view. For example, Kotlin lambdas,
file facade classes, multifile class facade/part classes, WhenMappings,
DefaultImpls. They can be distinguished from normal classes by the value
of `KotlinClassHeader.Kind` (which is the same as `Metadata.kind`).
Another theoretical option would be to throw exception at the point
where the `::class` expression is used, if the expression's type on the
left-hand side is a synthetic class. But we can't really do that since
it'll affect performance of most `<expression>::class` expressions.
So, construct a fake synthetic class instead, without any members except
equals/hashCode/toString, and without any non-trivial modifiers. It kind
of contradicts the general idea that kotlin-reflect presents anything
exactly the same as the compiler sees it, but arguably it's worth it to
avoid unexpected exceptions like in KT-41373.
In the newly added test, Java lambda check is muted but it should work
exactly the same as for Kotlin lambdas and other synthetic classes. It's
fixed in a subsequent commit.
#KT-41373 In Progress
Local classes and anonymous objects are normal classes and
kotlin-reflect can load all declarations and modifiers from them, and
support calling members, exactly in the same way as it does for normal
non-local classes.
#KT-41373 In Progress
kotlin-reflect works correctly already for Kotlin-generated local
classes and anonymous objects, but not for Java ones. This is fixed in a
subsequent commit.
#KT-41373 In Progress
Note that call-site class has no metadata for inlined local delegated
properties. Thus, for an inlined local delegated property we should
obtain declaration-site class as owner - otherwise, the corresponding
`PropertyReference` will have an owner without property metadata.
- Actualize muted K2 tests
- Actualize muted K1 tests with module systems because legacy Wasm test
infra had no respect for "// MODULE: ..." test directives
It basically can be replaced with IR interpreter. The only half-hack
was required in `PropertyReferenceLowering`. Const interpreter is
running before it, so we can't optimize some calls on const
properties that appear after this lowering. Solution is to inline
constants manually during property reference lowering.
Alexander Udalov