Previous episode was at 987a3460 (KT-45915).
Apparently, it's not enough to run psi2ir for all modules, and then
backend for all modules. If there are several modules in the chunk, IR
in any one of them can reference IR of any other one after psi2ir.
So we would end up in a situation where we're running codegen for the
first module, but the second module is completely unlowered. This would
break some assumptions in the codegen, for example in KT-49575, codegen
would see a reference to a top-level function from another module, and
would fail because the function has no containing class (since file
facades have not been generated yet!), and thus must be an intrinsic,
yet no such intrinsic is known to the codegen.
The solution is to run lowerings first on all modules, and then run
codegen on all modules. The kind of error explained above shouldn't be
possible anymore, because lowerings have to deal both with lowered and
unlowered code from other files all the time, so lowerings can't assume
that reference from other module is lowered either (or unlowered).
The code is not very nice, but hopefully it can be improved as soon as
we get rid of the old JVM backend (and maybe later with the migration to
FIR too).
#KT-49575 Fixed
This is needed in order to be able to invoke lowerings and codegen
separately, for cyclically dependent modules (KT-49575).
A side effect is that the two codegen phases are no longer configurable
via the phaser, i.e. absent in the -Xlist-phases and can't be disabled
or made verbose.
This will be used for two purposes:
1) call lowerings and codegen separately from
KotlinToJVMBytecodeCompiler to support cyclical module dependencies
(KT-49575)
2) split lowerings and codegen into separate modules
Instead, document that `KType.annotations` returns an empty list for
types created with `typeOf`. Annotations might be supported in the
future.
#KT-49573 Fixed
#KT-29919
evaluator fragments
- Refactor JvmIrCodegenFactory to allow for caller's choice of
lowerings.
- Refactor of SyntheticAccessorLowering to expose the accessibility
check used to determine the need for accessors.
- Replacement of field, method and constructor uses with corresponding
java.lang.reflection API via additional lowering running _before_
the existing IR pipeline.
- Emulating super calls in the context of class methods via new
compiler intrinsic.
- psi2ir: Add support for `_field` suffix on properties in the
evaluator for accessing underlying fields when applicable.
- Add `JvmGeneratorExtensions` point for determining whether a
property accessor has a user-supplied body in order to predict how
they are ultimately compiled for the JVM.
Putting them in the local variable table means that the debugger
needs to have special handling for parameters with specific names.
That forces us to generate mangled names for these.
Instead of also implementing the name mangling for FIR, this
change gets rid of the parameters from the LVT instead.
The `irGetField` utility uses the field's own type as the type of the
resulting expression. But the field's type does not make sense outside
of the place of declaration of the field if it references a generic type
parameter of the containing class. Using this non-sensical generic type
led, for example, to an error in Ieee754 intrinsic (KT-48648).
The type of the expression should be kept as is in
JvmPropertiesLowering, i.e. taken from `expression` which the lowering
is replacing with the field access.
#KT-48648 Fixed
Instead of a Boolean flag -Xserialize-ir, use modes: none,inline,all.
In "inline" mode, only information needed to deserialize bodies of inline
functions is serialized.
In the "all" mode, all declarations are serialized completely.
This is needed so that SharedVariablesLowering doesn't get confused, and
SharedVariablesLowering should run after TailrecLowering to properly
optimize tailrec calls in inline lambdas.
Using `kotlin.jvm.functions.Function{n+1}` (via
`getJvmSuspendFunctionClass`) for suspend functions was wrong in the
function reference lowering, because we didn't adapt the parameter types
by transforming the last type to Continuation and adding Object, and
generic signature ended up being incorrect.
Actually there was no need to use `kotlin.jvm.functions.Function{n+1}`
at all. We can just use the built-in
`kotlin.coroutines.SuspendFunction{n}` as a supertype, and it will be
mapped correctly later in codegen. It's not even needed to add the
`kotlin.coroutines.jvm.internal.SuspendFunction` marker manually, since
it's also handled by the codegen (see `IrTypeMapper.mapClassSignature`).
#KT-48732 Fixed
The JVM and newer Android runtimes treats that the same as if
there is no enclosing method. However, older Android runtimes
for Android 5 and 6 throw exceptions on reflective access
and even older runtimes have different behavior. To avoid
those issues, exclude <clinit> from enclosing method attributes.
^ KT-48754 Fixed
In case the cast value is used as a receiver to a private method call,
the cast is actually necessary, see KT-48927. Also, this optimization
has backfired once already (see kt48659_identityEqualsWithCastToAny.kt).
It seems that the best way to optimize these casts is not to generate
them in the first place, and/or use bytecode postprocessing.
Apparently the only kind of casts which need to be eliminated are those
which occur on an inline class to its supertype. Otherwise the
unsafe-coerce intrinsic is inserted at the incorrect place, and several
tests fail (uncastInlineClassToAnyAndBack.kt, genericOverride.kt,
classGenericOverride.kt).
#KT-48927 Fixed
Dmitry Petrov