this change fix issue with inlining lambda in inline function which(function) inlined from other library.
E.g.
> cat i-lib.kt
class _special_class(val v:Int)
class _special_class1(val v:Int)
class __helper(val v:Int)
inline fun foo(h: __helper): Int {
val sum = h.op {
_special_class(it.v)
}.v
return sum
}
inline fun __helper.op(block:(_special_class1) -> _special_class) = block(_special_class1(v))
> cat i-main.kt
fun main() {
val h = __helper(42)
println(foo(h))
}
Here how the incorrect parent affects debug information:
(lldb) target create "program.kexe"
Current executable set to '/Users/minamoto/ws/kotlin-native/program.kexe' (x86_64).
(lldb) command source -s 0 'i-test.lldb'
Executing commands in '/Users/minamoto/ws/kotlin-native/i-test.lldb'.
(lldb) b i-lib.kt:8
Breakpoint 1: where = program.kexe`kfun:#main(){} + 435 [inlined] foo + 98 at i-main.kt:3, address = 0x00000001000540e3
(lldb) r
Process 70550 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00000001000540e3 program.kexe`kfun:#main(){} [inlined] foo at i-lib.kt:9:7
6 inline fun foo(h: __helper): Int {
7 val sum = h.op {
8 _special_class(it.v)
-> 9 }.v
^
10 return sum
11 }
12
Target 0: (program.kexe) stopped.
the parent of lambda is i-main.kt instead of i-lib.kt, and offsets calculated against wrong file.
Here is behaviour with fix:
(lldb) target create "program.kexe"
Current executable set to '/Users/minamoto/ws/.git-trees/minamoto/debug-info/subprograms-with-missed-scopes/program.kexe' (x86_64).
(lldb) command source -s 0 '/Users/minamoto/ws/kotlin-native/i-test.lldb'
Executing commands in '/Users/minamoto/ws/kotlin-native/i-test.lldb'.
(lldb) b i-lib.kt:8
Breakpoint 1: where = program.kexe`kfun:#main(){} + 337 [inlined] <anonymous>_2 at i-lib.kt:14, address = 0x0000000100054bb1
(lldb) r
Process 70560 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100054bb1 program.kexe`kfun:#main(){} [inlined] <anonymous>_2 at i-lib.kt:8:24
5
6 inline fun foo(h: __helper): Int {
7 val sum = h.op {
-> 8 _special_class(it.v)
^
9 }.v
10 return sum
11 }
Target 0: (program.kexe) stopped.
The CodeCleaner treated all expressions with type `Nothing` as
non-terminating. This is not true for cases when return type is generic,
e.g:
```
fun <T> foo(): T = Any() as T
foo<Nothing>() // type: Nothing
```
This change makes the CodeCleaner more conservative, so that it doesn't
treat to such functions as non-terminating. This eliminates the need
to change call types from Nothing to Unit in
KotlinNothingValueExceptionLowering.
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
Since LocalDeclarationsLowering is a BodyLoweringPass, local
functions inside one declaration are handled independently of local
functions in the other declaration. This can lead to name clashes, in
case a local function with the same name and signature is declared in
overloads in the same container, which results in a signature clash
error in JVM IR.
The issue became more common with the introduction of adapted function
references, where psi2ir generates a local adapter-function with a
predefined name, which can easily clash with another reference to the
same target in an overload. This led to a compilation error when
bootstrapping Kotlin with JVM IR, for example in GradleIRBuilder.kt
where there are a lot of references to the same function.
The existing IrGenerationExtension is in the middle of IR construction
and basically requires plugins to work with the (deprecated) descriptors.
Since there are plans to change the IR extension point it makes sense to
introduce a temporary work-around to allow pure IR plugins to be
developed now, which could be ported to a more permanent API later.
Vasily Levchenko