Hierarchy of specially wrapped suspend function may have inconsistent
overridden descriptors: some of them may be wrapped, some unwrapped.
To mitigate this problem, currently it's proposed to render only
unwrapped functions, which are always have stable overridden descriptors
#KT-23809 Fixed
NB we use 'Intrinsics.areEqual(Double, Double)' and
'Intrinsics.areEqual(Float, Float)', because right now we take
nullability from the inferred type of the expression (which is 'Any?' in
the test cases).
We should probably reconsider this in case of more exact information
available from the data flow analysis, e.g., in case of
fun test(x: Any?) =
x is Serializable && x is Double? && x == 0.0
We statically know that 'x' is not null in 'x == 0.0' (although it's
neither nullability of it's numeric type 'Double?' nor the nullability
of the inferred type 'Any?').
There might be some edge effects in the performance related to byte code
size and preventive unboxing and so on.
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
Private suspend functions need to be generated as package-local, since
they are called from their continuations.
However, this means that they can be called from Java, which breaks
their private visibility.
Adding synthetic to them fixes the issue.
#KT-17584: Fixed
- Do not longer call hashCode on java/lang/Object but do this
on statically checked type.
- Do not longer call Intrinsics.areEqual but use directly
equals method on statically checked type.
Fix of https://youtrack.jetbrains.com/issue/KT-12330
Treat them like lambdas. This means:
1) Like local suspend lambdas, which become "non-suspend" after creating
jvmSuspendView, they do this as well
2) They both are generated with the same codegen.
3) They are treated differently only on front-end side.
#KT-20364: Fixed
Sometimes instead of {POP, GETSTATIC Unit.INSTANCE, ARETURN} sequence
the codegen emits {CHECKCAST Unit, ARETURN} sequence, which breaks tail
call optimization. By replacing CHECKCAST with ARETURN we eliminate
this issue.
#KT-19790: Fixed
Consider call chain `foo.bar.baz()` which has expected type `Int`
Elements `foo` and `bar` doesn't have expected type `Int`,
this is especially important in NI, because we use expected type for
candidate applicability
Before this change, the codegen used to generate beforeInlineMarker
in order to spill variables later. However, since the tailrec call
is replaced with jump, no afterInlineMarker is generated, leading to
inconsistency of these markers. Thus, the spilling fails.
This change disables generating of beforeInlineMarker.
#KT-21521: Fixed
Unlike ordinary lambdas suspend lambdas has create method which invokes
the constructor of the lambda object (continuation).
The inliner could not cope with this.
The previous change fixed the case of suspend lambda without receiver.
This change adds support of suspend lambdas with receiver.
#KT-21605: Fixed
in redundant locals elimination.
Since IgnoringCopySourceInterpreter ignores ALOADs and ASTOREs,
the source instruction of ALOAD K in {ALOAD N, ASTORE K, ALOAD K}
sequence is not ASTORE K. In this case we cannot simply replace K
with N, since there can be multiple {ALOAD N, ASTORE K} sequences
in separate branches. After replacement we get different stack
frames.
This change resolves this.
However, in ReturnUnitMethodTransformer we want to ignore copies
of the same GETSTATIC kotlin/Unit.INSTANCE, since we do not mess
with local variables and just replace ASTORE with ARETURN to help
tail-call optimization.
#KT-23373: Fixed
Use fake continuation instead of ALOAD 0 while inlining
Do not generate state machine for inner lambdas and inner objects,
which capture crossinline suspend lambda.
#KT-19159: Fixed
- Use direct access to property defined into companion object when
it is possible rather than always use an accessor to access the
property.
- Use direct access will speedup runtime performance.
- Avoid to generate useless accessors for companion properties.
Fix of https://youtrack.jetbrains.com/issue/KT-14258
Otherwise if Char value is a result of some erased generic call,
coercing it to I (primitive int) causes CCE at run-time.
#KT-23104 Fixed Target versions 1.2.40
Note that there are more places where assertions for inline classes should refined:
- lateinit vars
- values that come from Java
- type casts (interfaces to inline class type)
Mikhail Zarechenskiy