When collecting local properties for property initialization analysis, the nodes of the CFG were navigated. However, there are problems when trying to determine what local properties are defined within do-while loops. This is because the node order of a CFG does not always follow the FIR structure order. By converting the collector to a FIR visitor, we can maintain the structural order needed for finding properties defined within do-while loops. This does require some additional logic though to make sure we do not navigate into elements which are not part of the original graph navigation. ^KT-65911 Fixed
60 lines
1.3 KiB
Kotlin
Vendored
60 lines
1.3 KiB
Kotlin
Vendored
// FIR_IDENTICAL
|
|
// SKIP_TXT
|
|
// ISSUE: KT-64872, KT-65911
|
|
|
|
fun test1(cond1: Boolean) {
|
|
do {
|
|
if (cond1) continue
|
|
val cond2 = false
|
|
} while (<!UNINITIALIZED_VARIABLE!>cond2<!>) // cond2 may be not defined here
|
|
}
|
|
|
|
fun test2(cond1: Boolean, cond3: Boolean) {
|
|
do {
|
|
if (cond1) continue
|
|
val cond2 = false
|
|
} while (
|
|
run {
|
|
do {
|
|
if (cond3) continue
|
|
val cond4 = false
|
|
} while (<!UNINITIALIZED_VARIABLE!>cond4<!>) // cond4 may be not defined here
|
|
|
|
<!UNINITIALIZED_VARIABLE!>cond2<!> // cond2 may be not defined here
|
|
}
|
|
)
|
|
}
|
|
|
|
fun test3(cond1: Boolean, cond3: Boolean) {
|
|
do {
|
|
if (cond1) continue
|
|
val cond2 = false
|
|
} while (
|
|
run {
|
|
do {
|
|
if (cond3) continue
|
|
val cond4 = false
|
|
} while (<!UNINITIALIZED_VARIABLE!>cond2<!> && <!UNINITIALIZED_VARIABLE!>cond4<!>) // cond2 and cond4 may be not defined here
|
|
|
|
cond3
|
|
}
|
|
)
|
|
}
|
|
|
|
fun test4() {
|
|
try {
|
|
for (i in 0..100) {
|
|
var counter = 0
|
|
do {
|
|
try {
|
|
} finally {
|
|
counter++
|
|
}
|
|
} while (counter < 500)
|
|
}
|
|
} catch (e: Exception) {
|
|
e.cause?.let {}
|
|
e.let {}
|
|
}
|
|
}
|