suspend lambda.
The Name for the special destructuring declaration parameter was
incorrectly turned into a regular/non-special Name when the parameter
was moved to a field.
This undoes changes in
fbe66c3496
which broke calculation of the simple name of local classes in
reflection (the enclosing method was not a substring of the name of the
local class).
1. Postpone the computation of the signature for property
reference getters for extension properties until codegen time.
2. Generate metadata for static replacement functions instead
of the original functions.
It uses the same logic as an old back-end
(see SamType#createByValueParameter and genericSamProjectedOut.kt),
split into two parts:
1. When inserting SAM casts, use SamType#createByValueParamerer to get
the target SAM type.
2. When inserting implicit casts, cast SAM conversions as arguments of
methods of out-projected types to the original type of value parameter
instead of 'Nothing'.
Consider the following example:
Java:
public class J {
public static String foo() { return null; }
}
Kotlin:
fun check(fn: () -> Any) = fn()
fun test() = check { J.foo() }
When a lambda expression returns a value of platform type ('String!'),
corresponding lambda has platform type in its return type, which is
approximated to corresponding nullable type ('String?') in IR.
However, the lambda itself could occur in position with a functional
expected type ('() -> Any'). This implies an extra implicit cast on a
return value of lambda expression ('J.foo()'), although it conforms to
the return type of lambda.
When generating bodies for members implemented by delegation, invoke
corresponding delegate member, not an interface member. Otherwise we
might lose platform-specific nullability information in case of mixed
Kotlin-Java hierarchies, as in
implicitNotNullOnDelegatedImplementation.kt
When calling a generic Java generic method with vararg parameters with empty
vararg, incorrect array creation instruction was generated for primitive type:
NEWARRAY T_INT instead of ANEWARRAY java/lang/Integer. Here for Java method
public static <T> void takesVarargOfT(T x1, T... xs) {}
corresponding vararg parameter was considered to be of type 'Array<T>?',
which is not a non-null array type, so, NewArray intrinsic failed to generate
proper bytecode.
This commit fixes two issues in the existing implementation of translating primitive array types:
* IrType.getArrayElementType throws an exception when the receiver is a primitive array type, because IR expects primitive array types use symbols defined in IrBuiltIns, but fir2ir translation doesn't;
* IteratorNext.toCallable assumes all element types are boxed.
The first issue is fixed by changing the fir2ir type translation to use symbols in IrBuiltIns for primitive array types, and the second by not unboxing primitive types.
'descriptor -> descriptor.original' relation is often inconsistent
wrt 'containingDeclaration', parameters, and type parameters,
we have to introduce some workarounds here.
- Fix `toString` evaluation for unsigned types in FoldConstantLowering
- make corner cases around float/double evaluation work for K/JS
- remove usage of kotlin type
The idea is the same as in case of anonymous objects: they are created only
from Kotlin code, so we are sure, that the parameters are valid.
Also, the inliner complains on their transformations.
The main idea is the following: since we need to generate
(fake)continuations before inlining, we move IrClasses of suspend
lambdas and continuation classes of named functions into the functions.
Thus, it allows the codegen to generate them prior to inlining and
the inliner will happily transform them for us.
Because of that, lowerings which transform call-site function are likely
to change reference to lowered suspend lambdas or functions.
Hence, do not rely on references to lowered suspend lambdas or
functions, instead, rely on attributes.
Do not generate continuation for inline suspend lambdas.
Previously, inline suspend lambdas were treated like suspend functions,
thus we generated continuations for them. Now we just do not treat them
as suspend functions or lambdas during AddContinuationLowering.
We should add continuation parameter to them, however.
Do not generate secondary constructor for suspend lambdas, otherwise,
the inliner is unable to transform them (it requires only one
constructor to be present).
Generate continuation classes for suspend functions as first statement
inside the function.
This enables suspend functions in local object inside inline functions.
Since we already have attributes inside suspend named functions, we
just reuse them to generate continuation class names. This allows us
to close the gap between code generated by old back-end and the new
one.
If a suspend named function captures crossinline lambda, we should
generate a template for inliner: a copy of the function without
state-machine and a continuation constructor call. The call is needed
so the inliner transforms the continuation as well.
Refactor CoroutineTransformerMethodVisitor, so it no longer depends on
PSI.
This allows us to not generate redundant immutable collection
stubs. The code to generate the immutable collection stubs does
not deal well with thinking that all external declarations
come from Java.
