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
- Since neither IrProperty nor IrField is Type Parameter container
using of proprty's type parameter in IrField related code leads to
creation of "hanging" type parameters which should be considered as
incorrect IR.
- Such code designed to be prohibited in LV 1.5
- The fix makes use of erased type in such case
where type parameter is expected.
In case derived class has a field with the same name as the base class,
RenameFieldsLowering previously tried to rename one of the fields by
adding the "...$1" suffix, which led to NoSuchFieldError.
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.
Alexander Udalov