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.
NB here we have use derived class type with type arguments replaced
with star-projections. This emulates JVM erasure (to some degree),
but, unfortunately, that's best we can offer here at the moment.
if it overrides functions with another return type.
Otherwise, we cannot determine on call site that the function returns Unit
and cannot { POP, PUSH Unit } in order to avoid the situation when callee's
continuation resumes with non-unit result. The observed behavior is that
suspend function, which should return Unit, suddenly returns other value.
#KT-35262: Fixed
Before 1.4 tailrec function default arguments were evaluated
right-to-left instead of left-to-right. This is controlled
by a compile-time flag. This change adds support for the
right-to-left evaluation order when that flag is not set.
Get rid of "_lv12" in the test name, since it's actually a test on the
modern compiler. Also, avoid the commented "IGNORE_BACKEND: JVM_IR"
directive in another test to make JVM IR test failures more greppable.
Consider `fun <E : I> foo(a: Any?) = a as? E`, where I is an interface.
This check used to fail, because the `a == null` was missing, and
the `isInterface` stdlib method crashes if the first argument
is null. This change adds the null check.
Also this change prettifies the instance check in case of type parameter
left operand.
Since property accessor descriptors (unlike corresponding IR elements)
do not have type parameters, we need to take them from the corresponding
property to ensure the correct IR for delegated property accessors.
Alternatively, we could improve the lookup utilities and their usages to
always find the exact override of a symbol from
Collection/Iterable/CharSequence/etc, but since we need to load the
original symbol anyway in cases when the loop subject's type is a type
parameter, we might as well simplify everything and always reference the
original symbol.
Also improve exception message and removed unused declarations in
IrBackendUtils.kt.
Alexander Udalov