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
val y = 1
object { val x = y }
->
class XKt$1(`$y`: Int) { val x: Int = `$y` }
Note that `$y` is not stored in a field because it's not used outside
the primary constructor.
One exception is captured inline parameters on the JVM backend, as the
bytecode inliner uses field assignment instructions (setfield) to locate
them; removing the field is thus not possible.
- Replaced UNDEFINED_OFFSET with SYNTHETIC_OFFSET, it's required by
Native backend codegen
- Fixed missing overridden symbols
- Enforce adding fakeoverrides for members not overridden by backend
- Support more points for platform customisation
Simplify API of InlineConstTracker
In ConstLowering: Move transformer logic to another class to avoid mutable state. Avoid marking all files in module as module. Support of inner classes.
#KT-46506 Fixed
in annotations if underlying type is not nullable reference type.
Previously, it worked only for inline classes with primitive
underlying type and nullable reference type.
#KT-44133
This commit introduces a new entrypoint for the IR backend, and starts
the work of accomodating the evaluator in psi2ir.
The evaluator expects a certain class and method structure of the
compiled fragment, but PSI is only supplied for the actual fragment.
So, to that end, this commit introduces a new "front end" of psi2ir
that "synthesizes" the module, class and method structure around the
fragment before calling into the existing psi2ir pipeline to obtain
the IR for the fragment.
The primary complication so far is handling the captured variables of
the fragment: they are mapped to parameters of the method surrounding
the fragment, and passed as arguments on evaluation. Hence, the IR
translation of the fragment needs to remap captured variables to the
appropriate parameter, in essentially all places they can be referred
to in the fragment (and hence in psi2ir). This commit introduces a
decorated symbol table that intercepts symbol look-ups and remaps as
appropriate.
Other cases that dispatches based on descriptor (see
`CallGenerator.kt`) needs other metadata to generate correct code.
It also introduces a shim in DeserializedContainerSource in the psi2ir
pipeline to facilitate facade class generation for the code that is
being debugged (which are generated as "external ir declarations").
Finally, in passing we resolve a small leftover from previous
refactoring that left an asssertion re. allowing IR to _assign_ to
parameters of methods.
before checking whether they use the KProperty parameter. (Otherwise the
body is empty and the check always says that the parameter is unused.)
^KT-48825 Fixed
They may or may not be inlined later.
IDK how the test passes when both modules are compiled with the old
backend - perhaps this has something to do with the fact that when `f`
is compiled with the IR backend, the call to `x()` is followed by `pop`
and `getstatic kotlin/Unit.INSTANCE`? This is probably why the original
issue in kotlinx.coroutines reports that everything works fine with
kotlinx-coroutines-core:1.4.3.
^KT-46879 Fixed
^KT-48801 Fixed
The only way to make the compiler compile several modules with a
dependency loop is via the "build file", given by -Xbuild-file and used
in the JPS (IntelliJ built-in build system) plugin.
For the old frontend/backend it works like this: we _analyze_ sources of
all modules once, as if it's one big module, and then for each module,
we _generate_ (invoke backend) only sources of that module. Backend
needs to be invoked separately per-module because every module has its
own destination directory specified in the build file.
For JVM IR, this separation into just two steps, analyze and generate,
was problematic because there's psi2ir, which works like frontend, in
that it needs the global analysis result to be able to create and link
IR correctly. So, in case of JVM IR, we need to run psi2ir on the whole
module after analysis and before generation.
In this change, psi2ir is run on the whole module via
`CodegenFactory.convertToIr` (which does nothing in the old backend),
and then parts of the resulting IR module are extracted according to the
original separation of the combined module into individual modules via
`getModuleChunkBackendInput` by matching IrFile against KtFile. And
then, backend is run for each such module.
#KT-45915 Fixed
#KT-48668 Fixed
The steps of psi2ir and JVM backend need to be separated in the API
because in case of cyclic module dependencies (which are allowed in JPS)
psi2ir should be run first on all sources, and then JVM backend on each
module separately. `CodegenFactory.convertToIr` does nothing in the old
backend.
Also, move the ignoreErrors to GenerationState for simplicity.
Keeping the origin as LOCAL_FUNCTION_FOR_LAMBDA was a mistake as this
tells codegen nothing. Changing the origin in allows, for example,
removing the hack that detaches inline lambdas from the IR tree before
verification and codegen, or treating inline lambdas and inline
anonymous functions the same way.
This includes fake functions created for inline callable references.
#KT-48319 Fixed
#KT-47279 Fixed?
Together with extracting codegen to a separate (unrelated) module in the
future, hopefully it'll speed up the build of JVM IR by making it more
parallel, and helping incremental compilation to avoid recompiling code
that depends on lowerings because of `implementation` dependency.
The main idea is to remove dependencies on lowerings from other
backend.jvm code (mainly codegen), with the hope of extracting lowerings
and codegen to separate unrelated modules in the future.
To achieve this, code which is used both in lowerings and codegen is
moved to the "common" code, mainly JvmIrUtils/JvmIrTypeUtils.
- Move IrType-specific utilities to separate JvmIrTypeUtils.kt
- Extract JvmIrBuilder to a separate file
- Rename IrUtils.kt to JvmIrUtils.kt to be able to tell it apart from
numerous other IR utils files
Their call sites are all in the same file, so we can check whether the
declarations used in the inline function are accessible from all the
places where it will be inlined.
#KT-48736 Fixed
We can't apply "reuse loop variable as index variable" transformation
before local declarations lowering, otherwise it will affect captured
loop variable behavior, resulting in KT-48626.
Since it's JVM-specific, move it to JvmOptimizationLowering.
Georgy Bronnikov