Namely, anonymous objects defined in lambdas that have all captured
variables as loose fields instead of a single reference to the parent.
The question is, when a lambda inside an inline function defines an
anonymous object, and that object is not regenerated during codegen for
the inline function itself, but then has to be regenerated at call site
anyway, do we use an outer `this` or loose capture fields? For example,
before KT-28064:
inline fun f1(g: () -> Unit) = object { g() }
// -> f1$1 { $g: () -> Unit }
inline fun f2(g: () -> Unit) = f1 { object { g() } }
// -> f2$$inlined$f1$1 { $g: () -> Unit }
// f2$$inlined$f1$1$lambda$1 { this$0: f2$$inlined$f1$1 }
inline fun f3(g: () -> Unit) = f2 { object { g() } }
// -> f3$$inlined$f2$1 { $g: () -> Unit }
// f3$$inlined$f2$1$1 { this$0: f3$$inlined$f2$1 }
// f3$$inlined$f2$1$1$lambda$1 { this$0: f3$$inlined$f2$1$1 }
After KT-28064:
inline fun f2(g: () -> Unit) = f1 { object { g() } }
// -> f2$$inlined$f1$1 { $g: () -> Unit }
// f2$1$1 { $g: () -> Unit }
inline fun f3(g: () -> Unit) = f2 { object { g() } }
// -> f3$$inlined$f2$1 { $g: () -> Unit }
// f3$$inlined$f2$2 { ??? }
// f3$1$1 { $g: () -> Unit }
Should `???` be `this$0: f3$$inlined$f2$1` or `$g: () -> Unit`? This
commit chooses the latter for KT-28064 bytecode and keeps `this$0` when
inlining the old bytecode.
Here we want getting trailing comma in order to check its correctness
and then to report diagnostics. Now, note that if we have stub for
some PSI element, it means that we're definitely not in the compiler as
there are no stubs and we're definitely not in the current source file,
because in the current file we have full PSI tree in IDE.
Stubs are required, for example, for decompiled code and there is no
need to report any diagnostics about trailing comma there.
Also, because we don't have stubs for destructuring declarations,
one check for trailing commas is left without similar guard (
see resolveLocalVariablesFromDestructuringDeclaration method)
This commit fixes several IDE-tests:
MultiFileJvmBasicCompletionTestGenerated.testDoNotCompleteWithConstraints
MultiFileJvmBasicCompletionTestGenerated.testInImport
MultiFileJvmBasicCompletionTestGenerated.testInImportedFunctionLiteralParameter
MultiFileJvmBasicCompletionTestGenerated.testMoreSpecificExtensionGeneric
MultiFileJvmBasicCompletionTestGenerated.testNoGenericFunDuplication
MultiFileJvmBasicCompletionTestGenerated.testNotImportedExtensionFunction2
To avoid overload resolution ambiguity error in sources where everything
from both kotlin.reflect and kotlin.reflect.full is imported with a
star-import
Execution failed for task ':idea:idea-test-framework:test'.
> Could not resolve all files for configuration ':idea:idea-test-framework:testRuntimeClasspath'.
> Could not find org.jetbrains.intellij.deps.completion:completion-ranking-kotlin:0.0.2.
...
Required by:
project :idea:idea-test-framework > project :idea
It looks like when resolving this dependency gradle doesn't check the list of repositories in :idea module.
Revert "[JS IR] Build hybrid versions of stdlib and kotlin.test"
This reverts commit b9f88350dd.
Revert "[JS IR] Add gradle plugin integration tests"
This reverts commit d872b27663.
Revert "Update bootstrap"
This reverts commit bc47594c7a.
Revert "[JS IR] Support generating both IR and pre-IR libraries"
This reverts commit 1b8df45bfe.
returns Unit. The reason is the same as in the previous commit.
If the callable is tail-call and its callee returns something other that
Unit and suspends, on resume the result of the call will not be Unit.
#KT-34703
returning Unit. Because on resume the result might be not a Unit if
the callee is tail-call and its callee return something different from
Unit and suspends.
Luckily, we generated ReturnsUnitMarker on such calls in all release
versions since 1.3. So, even if the code is inline and generated by
older versions, it will still work correctly.
The only version of the compiler, which does not generate the markers,
is 1.3.60-eap-76, because we did not generate the markers since
cc06798e2c. But I think, this is not
an issue.
#KT-34703
pyos