Anton Bannykh
779d9aafe7
Consider an import from an inline function invocation. If it is being called from another inline function, it should be defined in a special way (e.g. `$$importsForInline$$.foo`) so that the compiler knows where to load transitive dependencies from. What's more, the declaration itself should be inside the inline function wrapper. Otherwise it should be defined in a regular way (e.g. `$module$bar.foo` among other top-level imports). By default the imports are loaded in the first form, and transformed into the second one when needed. To check whether this transformation the following predicate is used: `inlineFunctionDepth == 0`. At the moment the mentioned variable is increased upon visiting an inline function declaration (`defineInlineFunction`), and upon visiting an unknown (not visited before) inline function invocation. It seems that instead the variable should be increased when processing an existing inline function wrapper. At that point a new place to put import definitions (`statementContextForInline`) is set. Due to way JS code is generated (lambda's come before their call sites) this issue seems to have been masked. Primary class constructors are a special case - they come before any other declaration within. Hence a lambda invocation inside a constructor leads to incorrect import definition.
24 lines
286 B
Kotlin
Vendored
24 lines
286 B
Kotlin
Vendored
// EXPECTED_REACHABLE_NODES: 1192
|
|
// IGNORE_BACKEND: JS_IR
|
|
|
|
// MODULE: lib
|
|
// FILE: lib.kt
|
|
|
|
|
|
inline fun baz() = pp()
|
|
|
|
fun pp(): String = "OK"
|
|
|
|
// MODULE: mid(lib)
|
|
// FILE: mid.kt
|
|
|
|
fun bar() {
|
|
foo()
|
|
}
|
|
|
|
inline fun foo()= baz()
|
|
|
|
// MODULE: main(mid)
|
|
// FILE: main.kt
|
|
|
|
fun box() = foo() |