Mangle invocations of functions with value classes in signature which
override (directly or indirectly) a method declared in Kotlin code.
Otherwise, NoSuchMethodError is being thrown.
^KT-55945: 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
The incremental option will prevent creating file if there is an incremental cache from TS compiler even if the file doesn't exist.
The situation could happen if `./gradlew clean` was executed (js file will be removed and ts incremental cache - not)
Merge-request: KT-MR-10229
Merged-by: Artem Kobzar <Artem.Kobzar@jetbrains.com>
Before this fix, changes that were made to the arguments list by calling
argumentList.transformArguments() were overriden by replaceArgumentList.
This fixes reverses the order in which these calls are made.
This also aligns the logic between the completion of qualified accesses
and delegated constructor calls.
#KT-59102 Fixed
It was happening because for MyClass.foo we didn't set overriddenSymbols
properly because in ClassMemberGenerator.convertFunctionContent we
used incorrect containingFirClass that was pointing to anonymous class
instead of MyClass.
^KT-58902 Fixed
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
When an annotation constructor value parameter is annotated with the
very same annotation, FIR2IR went in an infinite loop when trying
to generate it.
To fix this, the constructor is added to the Fir2IrDeclarationStorage
cache before generating the value parameters.
To accommodate for the missing parameters, the value arguments count
is determined using the FIR.
Earlier, it wasn't really important but after the previous commit
when JvmMappedScope semantics has been changed, we erroneously
started loading `toCharArray` as a member to String because
its jvmDescriptor was computed to "toCharArray()Lkotlin/CharArray",
while hardcoded information that prevents it from loading expect
"toCharArray()[C" there.
^KT-57694 In progress
The test is not in any way JVM-specific, but it fails on the JS BE
because of different fq-names of stdlib symbols on JVM and JS.
The fix is in progress. Mute the test until the fix is ready.
Artem Kobzar