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.
Use the same instances from class declaration instead
Otherwise, primary constructor value parameter types when used
in the class body are considered as different from types
based on the class type parameters
See the test genericConstructors.kt, before this commit
"id" call was reported in inapplicable
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.
Dmitriy Novozhilov