Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
Code generation for the intrinsic `jvmDebuggerInvokeSpecialIntrinsic`
includes dispatch receiver, but ignores arguments
passed to a super-call. This change passes arguments in the IR
representation in an array, and during the codegen the array is
unpacked and the bytecode is generated for the elements,
right before generating the actual `INVOKESPECIAL`.
#KT-63848 fixed
Merge-request: KT-MR-13270
Merged-by: Alexander Kuznetsov <Aleksander.Kuznetsov@jetbrains.com>
Try to use `IrModuleFragment` instead of `ModuleDescriptor`. This change
is required for the evaluate expression in IDE. When we compile
some code fragment with inline function call that has an anonymous
object in callee, we will get incorrect behavior. Code fragment is
wrapped in `EvaluatorModuleDescriptor` and we accidentally
think that inline call and callee are in different modules that
leads to an error in `AnonymousObjectTransformer.doTransform`.
#KT-63454 Fixed
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
Create a nested hash map with names as keys that are easier to compute
than the whole `Key`. It helps to substantially reduce the number of
computed FqName instances, since intrinsics are queried on generation of
each call.
Also put intrinsic query a bit lower in SyntheticAccessorLowering, after
operations which are easier to compute.
The only case when erasure matters in a context of materialization of
`PromisedValue` is when the type is a type parameter which upper bound
is an inline class. Since `PromisedValue::materializeAt` is a hot spot
and `eraseTypeParameters` is an expensive operation, we should not do
type erasure in other cases.
trackFakeOverrideMethod in JvmSignatureClashDetector is modified to
ignore fake overrides to prevent duplicate tracking of such methods,
improving efficiency
Do not try to find PSI element, but always use the IR element offsets
instead. This greatly simplifies test data because we don't need to have
custom PSI- and LT- based diagnostic ranges in every test, and K1/K2
behavior also is mostly the same.
The exact offset ranges are not as important for backend diagnostics, so
it's better to have K2+PSI and K2+LT behaving the same.
This fixes the following
FirLightTreeDiagnosticsTestWithJvmIrBackendGenerated tests:
testPropertyInlineCycle
testInlineCycle
testSuspendInlineCycle
testIndirectInlineCycle
#KT-59586
Move language version settings, compiler configuration and different
flags there, and use this config everywhere in both backends instead of
GenerationState.
This will hopefully make GenerationState less of a "god object" and
remove the need to have it available everywhere, in particular in JVM IR
lowerings code, in the future.
Also, future refactorings will make it easier to inject backend-specific
behavior into common code, so that we would not need to handle support
of new features in the old backend.
Implementation is very similar to the `enumValues` intrinsic.
Java enums and old (pre-1.9) Kotlin enums will be supported in a
subsequent commit.
#KT-59710
Function `apiVersionIsAtLeast` was introduced to be able to have
different inline function content inlined to user code call sites
depending on their api version settings. Thus, it should not be
compile-time evaluated when being called in the body of inline stdlib
function.
^KT-59452: 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
Nikita Nazarov