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.
The condition on the relationship between the current class and the type
of the receiver for protected members was the opposite of what the JVMS
says, and yet somehow mostly worked?
#KT-48331 Fixed
#KT-20542 Fixed
Companion objects are exported as ParentClass.Companion.
Companion object's members are not exposed to its parent class —
one must reference the companion object explicitly if they want to
access its members.
#KT-43783 Fixed
Elena Lepilkina