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.
Previously we exported main function only.
Extend this feature to arbitrary number of annotated functions.
Type restrictions and conversions are similar to imported functions.
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
- change test runner to production mode when sources are being compiled
into klib and then klib is being translated into js, not directly from
kt to js
- fix IC cache format
- support IC tests
While annotations restrict the set of allowed types to a few final
built-ins, in arbitrary constants we can have array elements that are
some subtype of the array's element type.
#KT-48671 Fixed
Aleksei.Cherepanov