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
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
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
When BI/incomplete call is present in return argument, it will be
added to the main call-tree, leading to requirement violation in
`ConstraintSystemCompleter.getOrderedAllTypeVariables`
as after `FirBuilderInferenceSession.inferPostponedVariables` it will
be completed, and its type variables couldn't be found anymore
In K1, we actually do the same, but we are able to find type variables
of such calls due to architecture difference:
In K2, `getOrderedAllTypeVariables` uses FIR as the main source to
lookup
In K1, `getOrderedAllTypeVariables` uses resolution atom tree, where
candidate/CS of the call is still available after
`inferPostponedVariables`
In fact, all incomplete calls were analyzed in FULL mode according to
the contract of `FirBuilderInferenceSession.addPartiallyResolvedCall`.
Thus, it means we normally shouldn't add them to the main call-tree, but
accidentally do it as incomplete calls contain non-completed candidate
This particular commit addresses the problem partially, only
in cases when the expected return type for the lambda is Unit and when
the incomplete call is located in the last expression of the lambda
In such cases, we can skip the call from the last expression completely,
since all potential calls there were analyzed in FULL mode,
and couldn't introduce any useful info to the CS of the main call-tree
^KT-54294
Java declarations do not have a file parent, their outer element is
IrExternalPackageFragment.
The test did not fail in K1 only by accident, because there's an extra
IrTypeOperatorCall on the property reference's dispatch receiver, which
automatically makes it non-inlinable. In K2, it's IrGetField, so we were
trying to compute if its dispatch receiver is inlinable and for that we
tried to get its fileParent, which resulted in exception if it comes
from Java.
Also refactor PropertyReferenceDelegationTransformer.canInline a bit.
#KT-57955 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
The code in IrTypeMapper was incorrectly translated from
KotlinTypeMapper during the development of JVM IR. The
`classDescriptor.hasBigArity` condition in KotlinTypeMapper was checking
if the class represents a function or a suspend function with big arity,
and the suspend function part was lost during conversion.
This resulted in incorrect generic signature being generated, which led
to malformed type exceptions from reflection, and compilation errors
from kapt stub generation.
Also, change a comment in irCodegenUtils to avoid confusion of numbered
function types (kotlin.jvm.functions.Function1, ...) with the big-arity
type kotlin.jvm.functions.FunctionN.
#KT-58375 Fixed
Basically, the test checks that adding Enum.entries feature doesn't
break the existing code where it clashes with the user-defined "entries"
declaration; it's better to have a black-box test to be sure
that the compiler doesn't invoke something different at runtime
The test covers KT-53153 and KT-56587
Merge-request: KT-MR-9798
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
These two functions apparently are represented in Kotlin as methods
of `kotlin.String`. Because of that we accidentally treated them as
builtins.
To also minimize such cases, added filtration by return type. We are
allowing to interpret only these functions that have primitive or
unsigned return type.
#KT-57028 Fixed
since we generate the default getter in this case in
Fir2IrDeclarationStorage.createIrProperty, so the serialized metadata
should follow the same behavior.
#KT-57373 fixed
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
The changes to the irText test data result in the fact that we
now unconditionally unwrap substitution overrides of delegation targets
whereas before we built an unsubstituted scope of the type we delegate
to. If we delegate to a class A : B<C>, the unsubstituted scope of
A can still contain substitution overrides for inherited generic methods
from B<T> that we didn't unwrap before but do unwrap now.
#KT-57899 Fixed
Current qualified access resolving algo rely (likely incorrectly,
see #KT-58037) on a providers' "knowledge" about parent packages.
This commit adds this "knowledge" to k-lib based provider.
#KT-57353 fixed
Vladimir Sukharev