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.
Specifically, this commit improves the stepping behavior of the IR
backend around functions with defaults.
- Improved line numbers in the default handler itself for better
stepping when inlined.
- Improved source information on default arguments
- Improved test coverage of stepping behavior in old and IR backends.
Improves the stepping behaviour around inline methods with default
arguments. In particular, we now accurately step through the
evaluation of default arguments, but do _not_ spuriously show the exit
from the $default handler.
In BridgeTest::testFakeOverrideMisleadingImplementation,
order of generated bridges has changed slightly
(but the overall set of generated bridges remains the same).
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
If `mapLineNumber` was called in non-monotonic order, e.g. N then N+2
then N+1, the first two calls created a range that spans [N; N+2] but
the third call did not reuse it.
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
pyos