* Fix objects in inline functions and lambdas:
* Add common lowerings used in K/JS and K/Native
* Fix inline lambda call detection logic in presence of additional casts
Merge-request: KT-MR-8791
Merged-by: Svyatoslav Kuzmich <svyatoslav.kuzmich@jetbrains.com>
- Property getters and setters are not marked as `isExpect` even if the
corresponding property is. This commit fixes the generation of actual
stubs for such functions.
- The cause for KTIJ-24206 is that the `expect` function's parent is an
`IrFile` instead of an `IrClass`. This is because
`ExpectDeclarationsRemoveLowering` removes `expect` declarations
before `FileClassLowering` can replace `IrFile` parents.
- That behavior is normally okay, but breaks down when an `expect`
declaration has no associated `actual` declaration. In such cases,
`ExpectDeclarationsRemoveLowering` doesn't replace `expect` symbols in
expressions with their corresponding `actual` symbols, as it normally
would.
- The solution fills in `ExpectDeclarationsRemoveLowering`'s behavior
by replacing `expect` symbols for which no `actual` symbols exist with
stubs. See `stubOrphanedExpectSymbols`.
- To not mess with the lowerings, `stubOrphanedExpectSymbols` is invoked
during IR generation. It uses the same `ExpectSymbolTransformer`
as `ExpectDeclarationRemover`.
^KTIJ-24206 fixed
It is difficult to implement properly tail calls for a real coroutine (when there
are other non tail calls), because of continuation interception semantics. And the
benefits aren't clear at this point, so let's turn it off for now.
Add debug information for inline function parameters
Previously during debugging Kotlin/Native applications you couldn't inspect the inline function or inline lambda parameters. This happened because the debug information for them wasn't generated at all. To fix this issue we have to store the information about which expressions were inlined instead of which parameters. This commit adds a new mapping, which allows storing the required information during the inlining phase. The mapping is then reused during the bitcode generation phase to add the debug information for inline function parameters.
^KT-55440
If inline function A calls another inline function B,
we must use the original version of inline function A for inlining,
which doesn’t have inlined function B. Because during the inlining
process, we remap all occurrences of inline function A
to a temporary copy of function A, and if the function B
somehow uses function A (e.g. callable reference),
the built IR will have a reference to the temporary function,
not the original one. All these things lead to broken cross-module references.
This patch saves the original versions of all inline functions
before inlining and provides them during the inline process.
^KT-55930 Fixed
Newly added tests are basically copies of the existing tests on `until`.
Note that this operator is optimized for all backends, but the fact that
it's optimized is only checked for the JVM backend in bytecode text
tests.
#KT-53330 Fixed
There doesn't seem to be much value over a simple imperative code which
checks exactly the same things in the same order. The main downside of
the removed API is that it was more difficult to debug.
Dynamic Kotlin/Native compiler driver relies on a more "pure"
approach when data is explicitly passed between different phases.
SameTypeNamedCompilerPhase is not suitable for this purpose, so we need
a new type for that.
Artem Kobzar