Mads Ager
f128e5222a
In particular, the current line numbers could lead to stepping into the catch handler even when the code in the try did not throw an exception. This was caused by the code materializing the final value having the catch line number. This patch delays the materialization until the line number of the usage has been emitted.
74 lines
1.3 KiB
Kotlin
Vendored
74 lines
1.3 KiB
Kotlin
Vendored
// FILE: test.kt
|
|
|
|
fun foo() {
|
|
try {
|
|
mightThrow()
|
|
} finally {
|
|
"FINALLY"
|
|
}
|
|
|
|
val t = try {
|
|
mightThrow2()
|
|
} finally {
|
|
"FINALLY2"
|
|
}
|
|
}
|
|
|
|
var throw1 = false
|
|
var throw2 = false
|
|
|
|
fun mightThrow() {
|
|
if (throw1) throw Exception()
|
|
}
|
|
|
|
fun mightThrow2() {
|
|
if (throw2) throw Exception()
|
|
}
|
|
|
|
fun box() {
|
|
foo()
|
|
throw2 = true
|
|
foo()
|
|
// Never gets here.
|
|
throw1 = true
|
|
foo()
|
|
}
|
|
|
|
// The JVM backend steps back to line 11 when leaving the
|
|
// `mightThrow2` call. The JVM_IR backend does not. The
|
|
// JVM_IR behavior is consistent with what happens for the
|
|
// try-finally where the value is discarded which seems good.
|
|
|
|
// LINENUMBERS
|
|
// test.kt:29 box
|
|
// test.kt:4 foo
|
|
// test.kt:5 foo
|
|
// test.kt:21 mightThrow
|
|
// test.kt:22 mightThrow
|
|
// test.kt:7 foo
|
|
// test.kt:8 foo
|
|
// test.kt:10 foo
|
|
// test.kt:11 foo
|
|
// test.kt:25 mightThrow2
|
|
// test.kt:26 mightThrow2
|
|
// LINENUMBERS JVM
|
|
// test.kt:11 foo
|
|
// LINENUMBERS
|
|
// test.kt:13 foo
|
|
// test.kt:14 foo
|
|
// test.kt:10 foo
|
|
// test.kt:15 foo
|
|
// test.kt:30 box
|
|
// test.kt:31 box
|
|
// test.kt:4 foo
|
|
// test.kt:5 foo
|
|
// test.kt:21 mightThrow
|
|
// test.kt:22 mightThrow
|
|
// test.kt:7 foo
|
|
// test.kt:8 foo
|
|
// test.kt:10 foo
|
|
// test.kt:11 foo
|
|
// test.kt:25 mightThrow2
|
|
// test.kt:14 foo
|
|
// test.kt:13 foo
|