Even if a function is known to be tail call because it's a compiler
generated bridge, the tail return might still need to be added in case
of Unit return type.
* If `toArray` is inherited from Java, it may take an argument or
return a value of a flexible type, which looks nullable in IR;
* The returned array may also have `out` variance of the type
argument;
* `Array<T>` is not the same as `Array<Any?>` if `T` is neither `Any`
nor `in Something`, so presence of `toArray(): Array<T>` does not
mean we don't need to generate a new `toArray`.
Instead of generating overrides for getOwner/getName/getSignature in
each anonymous class representing a callable reference, pass them to the
superclass' constructor and store as fields. This occupies some small
memory but helps to reduce the size of the generated class files, and
will be helpful for adding further runtime information to callable
references, such as information about implicit conversions this
reference has been subject to.
Represent owner as java.lang.Class + boolean instead of
KDeclarationContainer, so that the unnecessary wrapping Class->KClass
wouldn't happen before it's needed, and also to make sure all callable
references remain serializable.
Note that the argument type where the "is declaration container a class"
is passed is int instead of boolean. The plan is to pass the
aforementioned implicit conversion information as bits of this same
integer value.
#KT-27362 Fixed
Instead of non-existing `kotlin.KotlinPackage`, which led to
NoClassDefFoundError as soon as reflection tried to call getOwner on a
builtin callable reference, use a reference to a new physical class
`kotlin.jvm.internal.Intrinsics$Kotlin`. This will allow to support
KT-17151.
Note that for API version less than 1.4, this will still lead to
NoClassDefFoundError, but this is not worse than the current situation
where it happens anyway.
The reference type is approximated in Psi2Ir, so we may get Nothing as
a reference type argument. Better look at the arguments of the
referenced function.
The SAM adapter is generate on declaration site. This is different
from the JVM approach.
`external fun interface` is banned for now.
Reusing interface declaration for the adapter is a hack which
reduces code size and makes importing/exporting the adapter
effortless.
Otherwise:
* should the dispatch receiver of a call be another call to a `suspend
fun` wrapped in something that is optimized away later, the owner of
the method will be incorrect;
* references to functions returning non-Unit but casted to `() ->
Unit` (allowed by new inference) might in fact not return Unit after
tail call optimization.
`invoke` in suspend lambdas overrides FunctionN.invoke, so the
refactored BridgeLowering already generates correct bridges there.
All the hack does is break overrides of interface suspend methods.
values within initializer blocks.
The issue occurs in code like this:
```
class C {
var b = true
init {
b = false // Missing PUTFIELD for this statement
}
}
```
Added a new statement origin for field initialization (at declaration)
instead of relying on `origin == null` in ExpressionCodegen to determine
whether to generate the initializations.
This was unintentionally broken in
d68a1898d0.
- [JS IR] Unmute fixed tests
- [IrText] Update testdata
- [WASM] Temporary turn wasm test off
- [FirText] Temporary turn fit text tests off
- [JVM IR] Turn off klib jvm test
- [IR] Add new test
Special bridges which are generated as a replacement for a non-final
fake override and use invokespecial to call the already existing
implementation in the superclass, should not be final. Otherwise we
can't generate an override for the original Kotlin function in a
subclass with the same JVM signature.
backends by removing IMPLICIT_NOTNULL casts from IrStringConcatenation
arguments.
Also fixed an issue where IrStringConcatenation can be lowered into
a null String instead of a literal "null" String if the lone argument
was a platform type String or String with enhanced nullability and the
value was null (e.g., "${FromJava.nullPlatformString()}").
The fact that this was a codegen box test was probably an abuse of the
testing infrastructure. It was never meant to pass, since it checks
presence of an error, and diagnostic tests aren't enough since they
might not check the full compiler execution.
Mark Punzalan