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
- Materialize unit when its value is actually needed.
- Special-case Unit_getInstance return type at codegen. It should be a
proper Unit object instead of a "void"
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.
Alexander Udalov