ClassCodegen bails before generating code if the filter supplied to
the GenerationState rejects it based on the containing file or class
declaration itself.
This is what Java 15+ does, and it permits accessing captured type
parameters via reflection. The alternative is to emit generic signatures
on the lambda methods, but that was disabled and I have no clue why.
^KT-52417 Fixed
This is somewhat suboptimal since this results in `::suspendInline`
generating 2 classes while `{ suspendInline() }` only creates 1, but
it's the best allowed by the existing hierarchy of classes in stdlib. At
least it works?
^KT-50832 Fixed
It's incorrect to take the first parameter type from the expression
itself because it can be nullable if smart casts are used. And if it's
nullable, it's mapped to the wrapper type and calling
`comparisonOperandType` for it makes no sense. Instead, take the type
from the callee function, as it's guaranteed to be mapped to a JVM
primitive type.
E.g. in `test1` function in the added test, the problem was that the
dispatch receiver type of the call expression is `Double?`, which is
mapped to `java/lang/Double`, whereas we clearly wanted to obtain the
primitive `D` (double) type.
#KT-52163 Fixed
This makes the debugger update the values when entering a recursive
call, and also uses fewer variable slots.
This may also work on the JS backend, but Native would probably require
something else.
^KT-47203 Fixed
`$$forInline` functions do not pass through the state machine generator,
and optimizing `Ref`s before that changes how assignments inside lambdas
passed to `suspendCoroutine`, etc. behave: without a `Ref`, the
assignment is not reflected in the continuation object, so the variable
has old value on resumption.
These functions will be optimized later, after they are inlined
somewhere and the state machine is generated.
^KT-52198 Fixed
This commit introduces support for calling and referencing local functions and
objects in evaluate expression on the IR backend.
The primary incision is a lowering inserted after Local Declaration Lowering,
that uses the intermediate data structures recorded by LDL to rewrite calls to
local functions to the appropriate function in the binary, instead of predicting
the compilation strategy. The required changes to the rest of the pipeline
facilitate piping the required data around.
The key to this transformation is that _captures by the local function_ must be
introduced as _captures by the fragment function_, such that the evaluator
infrastructure can find the appropriate values at run-time. This is necessary
due to the strategy of compiling local functions to static functions instead of
closures.
Additional test coverage of stepping behavior support the corresponding changes
in the Evaluator, part of the Kotlin Debugger plug-in.
In case there are several proxy functions for indy lambdas in the same
container, its names are "...__proxy", "...__proxy-0", "...__proxy-1",
..., yet before this change, only the first one was sanitized. So if
it's happening inside a constructor, `<init>` was left unrenamed which
led to ClassFormatError.
#KT-52040 Fixed
Locals introduced in the body of a do-while loop are not
necessarily live at the do-while condition. For example,
if there is a continue in the body before the declaration:
do {
if (shouldContinue(x))
continue
val y = 32 // not always defined in the condition
doSomething(y)
} while (x < 2)
For locals referenced in the condition such code is rejected
by the frontend because a local referenced in the condition
must be always defined when you get there.
However, locals that are not used in the condition were always
put in the local variable table. This leads to invalid locals
information which can trip of debuggers and other build tools
such as the D8 dexer.
This patch only puts in locals information for locals actually
referenced in the local variable table for the condition.
^Fixes KT-51754
If we do not do this, the state-machine builder will not know the type
of the ACONST_NULL, defaulting to Object, leading to VerifyError.
Alternatively, we could use LVT to deduce the type, but getting types
from LVT is something I got rid of long time ago, and I have no desire
to return it back.
Generating CHECKCAST hints the state-machine builder the type of the
variable avoiding the issue of VerifyError. However, this CHECKCAST
replaces StrictBasicValue.NULL_VALUE with BasicValue in
OptimizationBasicInterpreter. To preserve optimization on not-spilling
known nulls, introduce BasicValues, which represent typed nulls and
create BasicInterpreter, which is aware of them. This way we have the
best of two worlds - we do not spill known nulls, and we know the type
of ACONST_NULL.
#KT-51718 Fixed
along with source lines mapping, allows to "emulate" usage of the
PSI files which allows to extract source file and line mapping info
on every stage from source element.
It makes sense to use this mapping for the error reporting too.
Kristoffer Andersen