* 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.
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
A suspend stub for the abstract function
may be created in the context of the child function.
If on an incremental rebuild the stub is created from
the parent context (e.g. a file with the child is not modified),
the resulting LoweredDeclarationSignature will be different.
It will lead to a broken cross-module reference and broken JS code.
Therefore it is required to wrap the creation routine
into StageController::restrictTo() explicitly.
^KT-54934 Fixed
- Map generated explicit Unit returns to the closing brace of
the original body
- Name the continuation parameter as `$completion` to match the JVM BE,
and generate debug info for it (so that it appears in the 'names'
array in sourcemaps)
- Don't generate debug info for coroutine instantiation ceremony
(so that the user doesn't need to step in many times to get where they
want)
#KT-46276
Currently, compiler pipelines are heavily couples with
NamedCompilerPhase. Unfortunately, NamedCompilerPhase uses the same
type for Input and Output, thus it is not applicable to phases that
try to transform some data purely.
Thus, we separate this class into two, allowing to have a new
inheritor of NamedCompilerPhase with different Input and Output types.
Igor Chevdar