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.
'descriptor -> descriptor.original' relation is often inconsistent
wrt 'containingDeclaration', parameters, and type parameters,
we have to introduce some workarounds here.
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
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.
For example, synthetic `$annotations` methods for properties were
previously mangled to `$annotations-...`, which breaks annotation
loader, and fails an assert in ClassCodegen.generateMethod.
Normally, the fact that is was Unit was not visible as enum constructors
are lowered to normal class constructors anyway. The exception is when
the arguments are reordered, causing the incorrect return type to leak
into the block that holds temporary variables.
Change the treatment of default implementations on interfaces in JVM
compatibility mode. Previously, the IR backend moved the actual
default implementation to the DefaultImpls class, and then bridged to
it from the interface default. The old backend did the reverse, at the
cost of an additional accessor, in order to gain better binary
compatibility properties. See #2612 for discussion.
The accessor needs to call a specific implementation, so must be
performed through an `invokespecial`. We trick the
SyntheticAccessorLowering into doing this for us, by marking the
bridging call as a super call. We do this in want of an explicit
`invokespecial` Ir Node.
InterfaceDefaultCallsPhase previously assumed the old behaviour of the
IR backend (that calls to default implementations, e.g. `foo$default`
should target `DefaultImpls.foo$default`). But now the bridge to
foo$default resides on `DefaultImpls` already, causing that pass to
create a recursive loop. We cut that loop with a simple check.
In old BE we generate `create` for this kind of suspend lambdas, which,
like in simple suspend lambdas is responsible for putting arguments
(including extension receiver) to fields.
But, if number of parameters of suspend lambda (including receiver) >= 1,
there is no need to generate `create`, since `create` is called only by
`createCoroutine` and friends from stdlib, and there is no version of
`createCoroutine` for lambdas with multiple parameters.
Thus, in old BE we generate a redundant method, which affects method
count.
In JVM_BE we decided to 'inline' create into `invoke` for suspend lambdas
with multiple parameters.
Updated test checks, that large unsigned numbers are converted to corresponding
negative signed numbers properly. Using unsinged constants instead of signed
in test allows to remove supressed OI error as well as use test with NI.
Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
* Extract replacement of IrGetField/IrSetField into a separate
file-level lowering (should reduce the amount of work to linear in
the number of classes rather than potentially quadratic)
* Extract static backing field construction into JvmDeclarationFactory
and move that lowering after PropertiesToFields lowering to reduce
code duplication
Fun fact: this is not actually validated when loading the class; and
even when compiling a java file against a class file that does this,
only javac 9 has a check (1.8 and before simply crashes with
NullPointerException somewhere deep inside the compiler).
Mikhael Bogdanov