This fixes the problem in JVM IR backend which didn't pass bound
receiver value of an adapted function reference to the superclass
(kotlin/jvm/internal/AdaptedFunctionReference), which caused equals to
work incorrectly on such references (see changes in box tests).
Previously, bound adapted function reference was represented as
IrFunctionExpression to an adapter function which calls the callee. The
value of the bound receiver in that case could only be found in the body
of that adapter function. This is not very convenient, so this change
makes psi2ir produce a block of the adapter function + reference to it.
The bound receiver value is then found in the reference. This is
basically similar to what ProvisionalFunctionExpressionLowering is doing
for all function expressions. And since this IR structure is already
supported in FunctionReferenceLowering, the problem in the JVM IR is
fixed without any additional modifications.
However, inliners do not support this IR structure yet, see KT-38535 and
KT-38536.
since they are broken on JDK 11: they change Field.modifiers, which is prohibited
since JDK 9, because this private field is not exported.
Thus, we need to split the test into two: one with assertions enabled and the other
one with them disabled. Also, we need to run them in separate processes, for them
not to interfere each other.
#KT-27176 Fixed
Class.getClassLoader returns null for classes loaded by the system class
loader (the one used to start the application). In this case we need to
use ClassLoader.getSystemClassLoader. We already have an extension
`safeClassLoader` specifically for this purpose in reflection.jvm, but
forgot to use it in d59f2bcc80.
#KT-37707 Fixed
This fixes the weird cases when a class gets overwritten by an imperfect
copy, reduces the number of classes in the output if an inline function
contains an inline call that causes it to have regenerated anonymous
objects, and makes inlining of same module functions a bit faster in
general. On the other hand, this may increase memory footprint a bit
because classes cannot be flushed to the output jar, as the inliner
would not be able to locate classes for anonymous objects if they have
already been unloaded from memory.
The owner should always be the facade class, because the part class is
package-private and will be inaccessible from other package.
Note that in the old backend, function references already do have the
facade as the owner correctly, but property references don't, this is
reported as KT-37972.
The wrappers for conversions to nullable and non-nullable SAM types are
the same, so differentiating those has no effect other than class name
collisions.
Function references are now equal if they refer to the same function,
and if the parameter/return type adaptation, which happens when a
reference is used where some function type is expected, is exactly the
same. This includes the number of expected positional parameters (which
can be affected by defaults/varargs), whether the coercion of vararg
parameter to Array type happened, and whether the coercion of return
type to Unit happened.
#KT-37543 Fixed
For a class literal Type::class we are resolving Type as a constructor,
getting all diagnostics (about missing arguments, for example) and then
just not committing this trace with errors
#KT-37626 Fixed
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
We can only use IrStrinConcatentation to represent calls to Any?.toString
and toString calls on primitive types. Otherwise, x.toString() and "$x"
are observably different when x is a non-null type with null value
(e.g., an @NotNull value coming from Java).
even when arguments are to be rearranged.
Lambdas have no side effects, and storing them in temporary variables
prevents processing in the backend
(such as inserting continuation parameter in AddContinuationLowering).
1. Search for increment function in range element type, not in inferred
induction variable type
(which can be inappropriate, e.g., 'Nothing' in case of 'continue').
2. Handle nested loops with shared exit labels
(generated by JVM_IR for KT-37370 case).
KT-37370 KT-37373