It uses isStaticMethod to determine whether to set ACC_STATIC, which is
not correct (see PR #2341). This results in using incorrectly typed
opcodes (as all arguments are shifted by 1) when modifying the inlined
lambda's bytecode. For example, in the test added by this commit, these
opcodes are inserted to spill the stack into locals before calling
another inline function.
Because getMethodAsmFlags is used by the non-IR backend (see PR #2341
again for why changing stuff might not be a good idea), the proposed
solution is to ditch it completely and override generateLambdaBody in
IrExpressionLambdaImpl to use FunctionCodegen's IR-based flag
computation logic.
Mostly, these optimisations are picked from the old inference.
Also, remove exponential complexity for flexible types in approximation,
note that more correct fix for this would be to introduce new types
that corresponds just to platform types to avoid nullability problems,
but due to complexity it will be done later
#KT-31415 Fixed
- refactor script compiler to simplify extending it for repl
- add repl snippet compilation functions to the new scripting compiler
- extract util functions into appropriate files
- extract repl part into separate class
- extract bridge definition and related definitions into separate file
These properties have a very specific detail in their behavior, in that
the constructor's name is set to be "<init>". While this is OK for the
IR serialization, this may not always be expected in other cases, and
their rather common names (`name`, `fqNameSafe`) suggested that these
properties could be used in generic contexts.
Change all usages outside IR serialization to use
`IrDeclarationWithName.name` and nullable
`IrDeclarationWithName.fqNameWhenAvailable` instead
Although the intention of the change 9894c216c1 (#2341) was sensible, it
unfortunately caused the type mapper to map a default method incorrectly
under certain _undiscovered_ circumstances, which leads to incorrect
bytecode being generated. Specifically, this led to an exception:
java.lang.NoSuchMethodError : org.jetbrains.kotlin.idea.debugger.evaluate.KotlinDebuggerCaches$Companion.compileCodeFragmentCacheAware$default(Lorg/jetbrains/kotlin/psi/KtCodeFragment;Lcom/intellij/debugger/SourcePosition;Lkotlin/jvm/functions/Function0;ZILjava/lang/Object;)Lkotlin/Pair;
in a developer branch where this class was refactored and moved to
another module. I was not able to determine the exact reason of this
error, so I'm workarounding it by limiting this change to the IR backend
only (where it's needed), and postponing the investigation of the
failure above for now.
Mikhail Glukhikh