This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
For-in-string loop can be generated using specialized 'length' and
'charAt' method calls, and with cached string length.
Note that update of the string variable in loop body doesn't affect
loop execution semantics.
#KT-21322 Fixed Target versions 1.2.20
If the range expression is not a local variable (which can be updated in
the loop body affecting loop behavior, see KT-21354), we can cache the
array length, thus turning a for-in-array loop into a simple optimizable
counter loop.
#KT-21321 In Progress
Existing code for receiver generation accidentally worked in most cases
for object members imported by name. However, it generated strange
bytecode (such as
GETFIELD AnObject.INSTANCE
GETFIELD AnObject.INSTANCE
POP
), and worked incorrectly for augmented assignments.
#KT-21343 Fixed Target versions 1.2.20
This test introduces very special (for current implementation) case,
when we have smartcast indirectly, via some reified type parameter.
It covers recursive call inSmartCastManager.checkAndRecordPossibleCast(),
which wasn't previously covered by any test in testbase.
Expect members should always lose in resolution to non-expect members,
be it simple calls or callable references. Note that there should be
exactly one actual member for each expect member in correct code, so
both ways to check for expect vs non-expect are correct: either before
signature comparison, or after.
#KT-20903 Fixed
The problem is that when performing full analysis we do it in
a backward order while result for trivial vals is filled
in a forward one.
It turns out that reversedInstuctions might return a superset of
forward traversed instructions, e.g. in case of dead code in lambda.
At the same time result for trivial vals is constant
for any instruction, thus we can just return its constant value
and use it in the full analysis
#KT-20895 Fixed
Consider a context with uninitialized this, e.g.:
fun foo() {
val x = "..."
class Local(y: String) : Base(L@{ x + y })
}
Lambda 'L' is an argument of a super class constructor call.
Here 'this@Local' is not initialized yet. Thus local variables captured
in 'Local' can't be used. Instead, they should be captured by lambda 'L'
itself.
Note that lambda 'L' sees both 'x' and 'y' as local variables that
should be captured.
When in context with uninitialized this (generating arguments for super
type constructor or delegating constructor call), and a variable in
question is not found in the current context, use enclosing local lookup
to determine whether a local variable should be captured by a closure.
Enclosing class for closure is a class whose instance is captured by
closure as an outer 'this', and stored in a field 'this$0'.
Usually enclosing class for closure is an immediate outer class,
including classes for nested closures. For example:
class C {
fun foo() {}
val example1 = L1@ { foo() }
// Enclosing class for lambda 'L1' is 'C'
val example2 = L2a@ { L2b@ { foo() } }
// Enclosing class for nested lambda 'L2b'
// is a closure class for outer lambda 'L2a'
}
However, if the closure is created in a super type constructor call for
the outer class, corresponding instance is considered "uninitialized",
and can't be used as a proper class instance, and can't be referenced:
corresponding code is rejected by front-end.
class Outer {
fun foo() {}
inner class Inner : Base(L3@ { foo() })
// Enclosing class for lambda 'L3' is 'Outer',
// because 'Inner' is uninitialized in super type constructor call.
}
In CodegenAnnotatingVisitor, we maintain a stack of currently
uninitialized classes, and chose enclosing class for closure
as an inner-most surrounding class with initialized instance.
When generating code for this or outer class instance, we skip
contexts corresponding to classes with uninitialized instances.
This fixes a number of bytecode verification errors caused by incorrect
enclosing class for closure.
#KT-4174 Fixed Target versions 1.2.20
#KT-13454 Fixed Target versions 1.2.20
#KT-14148 Fixed Target versions 1.2.20
Fix generating multifile facade with all members private (in bytecode)
leading to delegate not being generated for corresponding light class
#KT-20966 Fixed
From Kotlin's point of view, everything in annotation classes is
non-abstract. A class inheriting from an annotation has a non-abstract
fake override for each property of the annotation class constructor. But
because members of annotation classes themselves were considered as
abstract in the bridge-generating code (see
DescriptorBasedFunctionHandle.isAbstract), there was a situation where a
concrete fake override has only one declaration among overridden
descriptors and it was abstract. This situation is invalid (a concrete
fake override must have exactly one concrete super-declaration),
therefore an exception was thrown.
The fix is to avoid considering annotation class members abstract for
the purposes of bridge generation. It's reasonably safe because no
bridges should be ever generated for annotation subclasses anyway,
because annotations can only have members with simple return types
(final and non-generic).
Note that in KT-19928, the problem is reproducible because of an
incorrect "inexact analysis" in light classes where "Target" is resolved
to an annotation class kotlin.annotation.Target. This behavior of the
analysis in light classes seems to do no harm otherwise, so it's not a
goal of this commit to change anything in that regard
#KT-19928 Fixed
Alexey Andreev