Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
> Condition 'isSuspendFunctionType' is always false when reached
The change in the native tests is needed, because K2
doesn't support disabling old language features
^KT-58623 Fixed
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
This commit adds missing pieces for the puzzle:
Annotation instantiation feature uses IrProperty's initializer to instantiate
properties from other modules that have default values which weren't
specified on call site.
To support this feature properly, Fir2IrVisitor should fill LazyIrProperty's
backing field initializer with information from Fir.
To get this information into Fir, FirMemberDeserializer should be able to read
it from KotlinJvmBinaryClass with AnnotationLoaderVisitorImpl. (klibs are unsupported for now)
There's a catch with enum entries references: we can't access session.SymbolProvider to resolve it
because we're still at the deserialization stage, and it can cause StackOverflow if enum is nested in the
same class (see RequiresOptIn.Level). To mitigate this, a new FirEnumEntryDeserializedAccessExpression is produced
instead; it is later replaced with the correct reference in the Fir2IrVisitor.
^KT-58137 Fixed
Also add test to loadJava folder with annotations default values that
verifies metadata loading
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>
Previously, updateTypeInBuilderInference was calling
updateTypeFromSmartcast to actually perform type update in
implicit receiver after stub types was inferred
Such action results in creation of following FIR:
FirSmartCastExpression(
original=FQAE(FirImplicitThisReference, typeRef=R|Inv<Stub>|)
typeRef=R|Inv<String>|
)
in receiver position during completion of calls
However, it wasn't the case in general situation due to
action of FirStubTypeTransformer, which, in turn visits and updates
type ref inside original expression, but only if there was at
least one call (that was completed) using that implicit receiver
As after such type update updateTypeFromSmartcast function does
nothing
Yet in situation, when there was only partially resolved calls
referencing that implicit receiver we actually create smart-cast
expression and don't update type
The change just removes usage of updateTypeFromSmartcast and
replaces is with direct type update
We still mutate state of implicit receiver, potentially
improperly, it should be addressed in future
^KT-54708
^KT-58365 Fixed
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
Denis.Zharkov