Fix for KT-1334 Class object in "Show Structure View" action #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
goodwinnk
added a commit
that referenced
this pull request
Feb 29, 2012
Fix for KT-1334 Class object in "Show Structure View" action
yanex
added a commit
that referenced
this pull request
Feb 18, 2015
Corrections/Suggestions in the first section
dnpetrov
added a commit
that referenced
this pull request
Feb 14, 2017
…lable value
KT-16194 Code with unnecessary safe call contains redundant boxing/unboxing for primitive values
Recognize some additional cases of trivial null checks and trivial instance-of checks.
A variable is "checked for null", if it is:
- a function parameter checked with 'INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull'
- checked for nullability with 'IFNULL/IFNONNULL'
- checked for nullability with 'INSTANCEOF'
(if objectref is instance-of T, then objectref is non-null)
Before analyzing nullability, introduce synthetic assumptions for execution branches
where a variable is guaranteed to be null or not null. For example, the following bytecode:
```
ALOAD 1 // Ljava/lang/String;
IFNULL L
<non-null branch>
L:
<null branch>
```
is transformed to
```
ALOAD 1
IFNULL L1
NEW java/lang/String
ASTORE 1 // tells analyzer that variable #1 is non-null
<non-null branch>
L:
<null branch>
L1:
ACONST_NULL
ASTORE 1 // tells analyzer that variable #1 is null
GOTO L
```
Note that such transformations are meaningful only for variables
that are checked for null at least twice.
After the analysis is performed on a preprocessed method,
remember the results for "interesting" instructions
and revert the preprocessing transformations.
After that, perform bytecode transformations as usual.
Do not transform INSTANCEOF to-be-reified, because reification at call site
can introduce null checks. E.g.,
```
inline fun <reified T> isNullable() = null is T
...
assert(isNullable<String?>())
```
dnpetrov
added a commit
that referenced
this pull request
Feb 14, 2017
…lable value
KT-16194 Code with unnecessary safe call contains redundant boxing/unboxing for primitive values
KT-12839 Two null checks are generated when manually null checking platform type
Recognize some additional cases of trivial null checks and trivial instance-of checks.
A variable is "checked for null", if it is:
- a function parameter checked with 'INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull'
- checked for nullability with 'IFNULL/IFNONNULL'
- checked for nullability with 'INSTANCEOF'
(if objectref is instance-of T, then objectref is non-null)
Before analyzing nullability, introduce synthetic assumptions for execution branches
where a variable is guaranteed to be null or not null. For example, the following bytecode:
ALOAD 1 // Ljava/lang/String;
IFNULL L
<non-null branch>
L:
<null branch>
is transformed to
ALOAD 1
IFNULL L1
NEW java/lang/String
ASTORE 1 // tells analyzer that variable #1 is non-null
<non-null branch>
L:
<null branch>
L1:
ACONST_NULL
ASTORE 1 // tells analyzer that variable #1 is null
GOTO L
After the analysis is performed on a preprocessed method,
remember the results for "interesting" instructions
and revert the preprocessing transformations.
After that, perform bytecode transformations as usual.
Do not transform INSTANCEOF to-be-reified, because reification at call site
can introduce null checks. E.g.,
inline fun <reified T> isNullable() = null is T
...
assert(isNullable<String?>())
dnpetrov
added a commit
that referenced
this pull request
Feb 15, 2017
…lable value
KT-16194 Code with unnecessary safe call contains redundant boxing/unboxing for primitive values
KT-12839 Two null checks are generated when manually null checking platform type
Recognize some additional cases of trivial null checks and trivial instance-of checks.
A variable is "checked for null", if it is:
- a function parameter checked with 'INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull'
- checked for nullability with 'IFNULL/IFNONNULL'
- checked for nullability with 'INSTANCEOF'
(if objectref is instance-of T, then objectref is non-null)
Before analyzing nullability, introduce synthetic assumptions for execution branches
where a variable is guaranteed to be null or not null. For example, the following bytecode:
ALOAD 1 // Ljava/lang/String;
IFNULL L
<non-null branch>
L:
<null branch>
is transformed to
ALOAD 1
IFNULL L1
NEW java/lang/String
ASTORE 1 // tells analyzer that variable #1 is non-null
<non-null branch>
L:
<null branch>
L1:
ACONST_NULL
ASTORE 1 // tells analyzer that variable #1 is null
GOTO L
After the analysis is performed on a preprocessed method,
remember the results for "interesting" instructions
and revert the preprocessing transformations.
After that, perform bytecode transformations as usual.
Do not transform INSTANCEOF to-be-reified, because reification at call site
can introduce null checks. E.g.,
inline fun <reified T> isNullable() = null is T
...
assert(isNullable<String?>())
mglukhikh
pushed a commit
that referenced
this pull request
Jun 26, 2018
Own tests on Constant Propagation created. This closes #1
calexHG
pushed a commit
to calexHG/kotlin
that referenced
this pull request
Aug 16, 2018
Attempting to avoid the currently occurring error:
Step JetBrains#1: Could not create service of type ScriptPluginFactory using BuildScopeServices.createScriptPluginFactory().
Step JetBrains#1: > Could not create service of type CrossBuildFileHashCache using BuildSessionScopeServices.createCrossBuildFileHashCache().
See gradle/gradle#3318.
skuzmich
added a commit
that referenced
this pull request
Nov 19, 2018
mglukhikh
added a commit
that referenced
this pull request
Feb 15, 2019
Alefas
pushed a commit
that referenced
this pull request
Apr 16, 2019
Alefas
pushed a commit
that referenced
this pull request
Apr 17, 2019
romanart
added a commit
that referenced
this pull request
Dec 19, 2019
kandersen
referenced
this pull request
in kandersen/kotlin
Feb 18, 2020
[FIR] Fix FIR2IR Types on SetVariable Expressions
mglukhikh
added a commit
that referenced
this pull request
May 13, 2020
vvlevchenko
added a commit
that referenced
this pull request
Jun 10, 2020
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.
vvlevchenko
added a commit
that referenced
this pull request
Jun 10, 2020
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.
vvlevchenko
added a commit
that referenced
this pull request
Jun 10, 2020
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.
vvlevchenko
added a commit
that referenced
this pull request
Jun 10, 2020
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.
mglukhikh
added a commit
that referenced
this pull request
Mar 18, 2021
pyos
added a commit
to pyos/kotlin
that referenced
this pull request
Aug 11, 2021
That code is convoluted, better take it slow to avoid accidentally breaking (or fixing) anything.
dsavvinov
added a commit
that referenced
this pull request
Dec 21, 2023
Step #1: just convert enabledOnCurrentHostFor(Klib|Binaries)Compilation to functions. This commit is a non-semantical change, next one will add a parameter to the function
dsavvinov
added a commit
that referenced
this pull request
Dec 21, 2023
Step #1: just convert enabledOnCurrentHostFor(Klib|Binaries)Compilation to functions. This commit is a non-semantical change, next one will add a parameter to the function
KotlinBuild
pushed a commit
that referenced
this pull request
Mar 11, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not.
KotlinBuild
pushed a commit
that referenced
this pull request
Mar 12, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
KotlinBuild
pushed a commit
that referenced
this pull request
Mar 14, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
KotlinBuild
pushed a commit
that referenced
this pull request
Mar 20, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
demiurg906
pushed a commit
that referenced
this pull request
Mar 22, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
yanex
pushed a commit
that referenced
this pull request
Mar 25, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
KotlinBuild
pushed a commit
that referenced
this pull request
Mar 26, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
KotlinBuild
pushed a commit
that referenced
this pull request
Apr 15, 2024
The Fir2Ir has two steps in terms of the annotation setup: Step #1. Creating `IrMutableAnnotationContainer` Step #2. Filling `IrMutableAnnotationContainer` with annotations When the `IrMutableAnnotationContainer` is out of the source module, `Fir2IrCallableDeclarationsGenerator` sets annotations for a `IrMutableAnnotationContainer` when creating its IR object. For example, when `foo()` defined in `B.kt` is called in file `A.kt`, and `A.kt` is a part of the source module while `B.kt` is a part of library, `Fir2IrCallableDeclarationsGenerator` sets annotations of `IrFunction` for `foo()`. On the other hand, if `foo()` is a part of the source module, `Fir2IrCallableDeclarationsGenerator` does not set annotations for it when creating `IrMutableAnnotationContainer` (Step #1). Later, when it fills contents of `IrMutableAnnotationContainer`, it conducts Step #2. However, if `foo()` is a part of the source module, but it is not in a compile target file, filling contents of `foo()` does not happen (because it is not a compile target). As a result, set up annotations for `foo()` is not done by Fir2Ir. This missing annotation setup causes a serious bug for Android Compose app. This commit updates code to decide whether we have to set up the annotations of `IrMutableAnnotationContainer` in Step #1 or not. We have to check not only if it is a part of the source code but also if it is a part of compile targets or not. ^KT-66532 Fixed
dsavvinov
added a commit
that referenced
this pull request
Apr 24, 2024
…ist/ Interop klibs are built into two steps: 1. Compile interop klibs in kotlin-native/platformLibs/build/konan/libs This is done in KonanInteropTasks with names like: 'compileKonanAndroid_arm64-mediaAndroid_arm64' 2. Move them to kotlin-native/dist/klib/platform This is done in regular Sync-tasks with names like: 'android_arm64-media' Some interop klibs depend on other interop klibs (e.g. android_arm64/media library depends on android_arm64/posix). This commit changes how this dependency is declared; Before: - KonanInteropTasks declared dependencies on raw files in kotlin-native/dist/klib/platform. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'kotlin-native/dist/klib/platform/android_arm64/o.j.k.n.p.posix'-dir - KonanInteropTasks declared dependencies on Sync-tasks, i.e. tasks from #1 declare dependencies on tasks from #2. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'android_arm64-posix' After: - KonanInteropTasks declare dependencies on raw files in kotlin-native/platformLibs/build/konan/libs. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'kotlin-native/platformLibs/build/konan/libs/android_arm64/o.j.k.n.p.posix' - KonanInteropTasks declare dependencies on other KonanInteropTasks. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'compileKonanAndroid_arm64-posixAndroid_arm64' This improves incapsulation and makes it less likely for inputs of these tasks to overlap with outputs of other tasks that write into dist/ (and overlapping outputs lead to error in Gradle)
dsavvinov
added a commit
that referenced
this pull request
May 13, 2024
…ist/ Interop klibs are built into two steps: 1. Compile interop klibs in kotlin-native/platformLibs/build/konan/libs This is done in KonanInteropTasks with names like: 'compileKonanAndroid_arm64-mediaAndroid_arm64' 2. Move them to kotlin-native/dist/klib/platform This is done in regular Sync-tasks with names like: 'android_arm64-media' Some interop klibs depend on other interop klibs (e.g. android_arm64/media library depends on android_arm64/posix). This commit changes how this dependency is declared; Before: - KonanInteropTasks declared dependencies on raw files in kotlin-native/dist/klib/platform. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'kotlin-native/dist/klib/platform/android_arm64/o.j.k.n.p.posix'-dir - KonanInteropTasks declared dependencies on Sync-tasks, i.e. tasks from #1 declare dependencies on tasks from #2. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'android_arm64-posix' After: - KonanInteropTasks declare dependencies on raw files in kotlin-native/platformLibs/build/konan/libs. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'kotlin-native/platformLibs/build/konan/libs/android_arm64/o.j.k.n.p.posix' - KonanInteropTasks declare dependencies on other KonanInteropTasks. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'compileKonanAndroid_arm64-posixAndroid_arm64' This improves incapsulation and makes it less likely for inputs of these tasks to overlap with outputs of other tasks that write into dist/ (and overlapping outputs lead to error in Gradle)
KotlinBuild
pushed a commit
that referenced
this pull request
May 14, 2024
…ist/ Interop klibs are built into two steps: 1. Compile interop klibs in kotlin-native/platformLibs/build/konan/libs This is done in KonanInteropTasks with names like: 'compileKonanAndroid_arm64-mediaAndroid_arm64' 2. Move them to kotlin-native/dist/klib/platform This is done in regular Sync-tasks with names like: 'android_arm64-media' Some interop klibs depend on other interop klibs (e.g. android_arm64/media library depends on android_arm64/posix). This commit changes how this dependency is declared; Before: - KonanInteropTasks declared dependencies on raw files in kotlin-native/dist/klib/platform. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'kotlin-native/dist/klib/platform/android_arm64/o.j.k.n.p.posix'-dir - KonanInteropTasks declared dependencies on Sync-tasks, i.e. tasks from #1 declare dependencies on tasks from #2. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declared a dependency on 'android_arm64-posix' After: - KonanInteropTasks declare dependencies on raw files in kotlin-native/platformLibs/build/konan/libs. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'kotlin-native/platformLibs/build/konan/libs/android_arm64/o.j.k.n.p.posix' - KonanInteropTasks declare dependencies on other KonanInteropTasks. Example: 'compileKonanAndroid_arm64-mediaAndroid_arm64' declares a dependency on 'compileKonanAndroid_arm64-posixAndroid_arm64' This improves incapsulation and makes it less likely for inputs of these tasks to overlap with outputs of other tasks that write into dist/ (and overlapping outputs lead to error in Gradle)
nikitabobko
added a commit
that referenced
this pull request
Dec 3, 2024
exception: org.jetbrains.kotlin.codegen.CompilationException: Back-end (JVM) Internal error: Couldn't transform method node:
main ()V:
L0
LINENUMBER 16 L0
ICONST_1
ANEWARRAY java/lang/String
ASTORE 1
ALOAD 1
ICONST_0
LDC "foo"
AASTORE
ALOAD 1
INVOKEVIRTUAL Foo$Companion.of ([Ljava/lang/String;)LFoo;
ASTORE 0
L1
LINENUMBER 18 L1
RETURN
L2
LOCALVARIABLE foo LFoo; L1 L2 0
MAXSTACK = 3
MAXLOCALS = 2
File is unknown
The root cause org.jetbrains.org.objectweb.asm.tree.analysis.AnalyzerException was thrown at: org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:82)
at org.jetbrains.kotlin.codegen.TransformationMethodVisitor.visitEnd(TransformationMethodVisitor.kt:89)
at org.jetbrains.org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:783)
at org.jetbrains.org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:772)
at org.jetbrains.kotlin.backend.jvm.codegen.ClassCodegen.generateMethod(ClassCodegen.kt:453)
at org.jetbrains.kotlin.backend.jvm.codegen.ClassCodegen.generate(ClassCodegen.kt:168)
at org.jetbrains.kotlin.backend.jvm.FileCodegen.lower(JvmPhases.kt:40)
at org.jetbrains.kotlin.backend.common.phaser.PhaseFactoriesKt.createFilePhase$lambda$4(PhaseFactories.kt:88)
at org.jetbrains.kotlin.backend.common.phaser.PhaseBuildersKt$createSimpleNamedCompilerPhase$1.phaseBody(PhaseBuilders.kt:68)
at org.jetbrains.kotlin.config.phaser.SimpleNamedCompilerPhase.phaseBody(CompilerPhase.kt:215)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invokeSequential(performByIrFile.kt:52)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:42)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:28)
at org.jetbrains.kotlin.config.phaser.SameTypeNamedCompilerPhase.phaseBody(CompilerPhase.kt:160)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:28)
at org.jetbrains.kotlin.config.phaser.SameTypeNamedCompilerPhase.phaseBody(CompilerPhase.kt:160)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.config.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:62)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.invokeCodegen(JvmIrCodegenFactory.kt:375)
at org.jetbrains.kotlin.codegen.CodegenFactory.generateModule(CodegenFactory.kt:42)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.generateModuleInFrontendIRMode(JvmIrCodegenFactory.kt:437)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineKt.generateCodeFromIr(jvmCompilerPipeline.kt:188)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineKt.runBackend(jvmCompilerPipeline.kt:80)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileModule(jvmCompilerPipelineLightTree.kt:264)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileSingleModuleUsingFrontendIrAndLightTree(jvmCompilerPipelineLightTree.kt:231)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileModulesUsingFrontendIrAndLightTree(jvmCompilerPipelineLightTree.kt:86)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:143)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:40)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:102)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:316)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:294)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:258)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMainNoExit(CLICompiler.kt:395)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMainNoExit$default(CLICompiler.kt:388)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMain(CLICompiler.kt:382)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:251)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jetbrains.kotlin.preloading.Preloader.run(Preloader.java:87)
at org.jetbrains.kotlin.preloading.Preloader.main(Preloader.java:44)
Caused by: org.jetbrains.org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction #10 INVOKEVIRTUAL Foo$Companion.of ([Ljava/lang/String;)LFoo;: Cannot pop operand off an empty stack.
current: {
locals: [
#0: org.jetbrains.org.objectweb.asm.tree.analysis.SourceValue@0
#1: org.jetbrains.org.objectweb.asm.tree.analysis.SourceValue@4eba373c
]
stack: size=0 []
}
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:82)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyze(FastAnalyzer.kt:53)
at org.jetbrains.kotlin.codegen.optimization.boxing.PopBackwardPropagationTransformer$Transformer.transform(PopBackwardPropagationTransformer.kt:58)
at org.jetbrains.kotlin.codegen.optimization.boxing.PopBackwardPropagationTransformer.transform(PopBackwardPropagationTransformer.kt:41)
at org.jetbrains.kotlin.codegen.optimization.transformer.CompositeMethodTransformer.transform(CompositeMethodTransformer.kt:25)
at org.jetbrains.kotlin.codegen.optimization.OptimizationMethodVisitor.performTransformations(OptimizationMethodVisitor.kt:74)
at org.jetbrains.kotlin.codegen.TransformationMethodVisitor.visitEnd(TransformationMethodVisitor.kt:67)
... 43 more
Caused by: java.lang.IndexOutOfBoundsException: Cannot pop operand off an empty stack.
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.pop(Frame.java:228)
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.executeInvokeInsn(Frame.java:643)
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.execute(Frame.java:573)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeInstruction(FastAnalyzer.kt:111)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:74)
... 49 more
nikitabobko
added a commit
that referenced
this pull request
Dec 13, 2024
exception: org.jetbrains.kotlin.codegen.CompilationException: Back-end (JVM) Internal error: Couldn't transform method node:
main ()V:
L0
LINENUMBER 16 L0
ICONST_1
ANEWARRAY java/lang/String
ASTORE 1
ALOAD 1
ICONST_0
LDC "foo"
AASTORE
ALOAD 1
INVOKEVIRTUAL Foo$Companion.of ([Ljava/lang/String;)LFoo;
ASTORE 0
L1
LINENUMBER 18 L1
RETURN
L2
LOCALVARIABLE foo LFoo; L1 L2 0
MAXSTACK = 3
MAXLOCALS = 2
File is unknown
The root cause org.jetbrains.org.objectweb.asm.tree.analysis.AnalyzerException was thrown at: org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:82)
at org.jetbrains.kotlin.codegen.TransformationMethodVisitor.visitEnd(TransformationMethodVisitor.kt:89)
at org.jetbrains.org.objectweb.asm.MethodVisitor.visitEnd(MethodVisitor.java:783)
at org.jetbrains.org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:772)
at org.jetbrains.kotlin.backend.jvm.codegen.ClassCodegen.generateMethod(ClassCodegen.kt:453)
at org.jetbrains.kotlin.backend.jvm.codegen.ClassCodegen.generate(ClassCodegen.kt:168)
at org.jetbrains.kotlin.backend.jvm.FileCodegen.lower(JvmPhases.kt:40)
at org.jetbrains.kotlin.backend.common.phaser.PhaseFactoriesKt.createFilePhase$lambda$4(PhaseFactories.kt:88)
at org.jetbrains.kotlin.backend.common.phaser.PhaseBuildersKt$createSimpleNamedCompilerPhase$1.phaseBody(PhaseBuilders.kt:68)
at org.jetbrains.kotlin.config.phaser.SimpleNamedCompilerPhase.phaseBody(CompilerPhase.kt:215)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invokeSequential(performByIrFile.kt:52)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:42)
at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:28)
at org.jetbrains.kotlin.config.phaser.SameTypeNamedCompilerPhase.phaseBody(CompilerPhase.kt:160)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.backend.common.phaser.CompositePhase.invoke(PhaseBuilders.kt:28)
at org.jetbrains.kotlin.config.phaser.SameTypeNamedCompilerPhase.phaseBody(CompilerPhase.kt:160)
at org.jetbrains.kotlin.config.phaser.NamedCompilerPhase.invoke(CompilerPhase.kt:111)
at org.jetbrains.kotlin.config.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:62)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.invokeCodegen(JvmIrCodegenFactory.kt:375)
at org.jetbrains.kotlin.codegen.CodegenFactory.generateModule(CodegenFactory.kt:42)
at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.generateModuleInFrontendIRMode(JvmIrCodegenFactory.kt:437)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineKt.generateCodeFromIr(jvmCompilerPipeline.kt:188)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineKt.runBackend(jvmCompilerPipeline.kt:80)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileModule(jvmCompilerPipelineLightTree.kt:264)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileSingleModuleUsingFrontendIrAndLightTree(jvmCompilerPipelineLightTree.kt:231)
at org.jetbrains.kotlin.cli.jvm.compiler.pipeline.JvmCompilerPipelineLightTreeKt.compileModulesUsingFrontendIrAndLightTree(jvmCompilerPipelineLightTree.kt:86)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:143)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:40)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:102)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:316)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:294)
at org.jetbrains.kotlin.cli.common.CLICompiler.exec(CLICompiler.kt:258)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMainNoExit(CLICompiler.kt:395)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMainNoExit$default(CLICompiler.kt:388)
at org.jetbrains.kotlin.cli.common.CLICompiler$Companion.doMain(CLICompiler.kt:382)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:251)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jetbrains.kotlin.preloading.Preloader.run(Preloader.java:87)
at org.jetbrains.kotlin.preloading.Preloader.main(Preloader.java:44)
Caused by: org.jetbrains.org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction #10 INVOKEVIRTUAL Foo$Companion.of ([Ljava/lang/String;)LFoo;: Cannot pop operand off an empty stack.
current: {
locals: [
#0: org.jetbrains.org.objectweb.asm.tree.analysis.SourceValue@0
#1: org.jetbrains.org.objectweb.asm.tree.analysis.SourceValue@4eba373c
]
stack: size=0 []
}
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:82)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyze(FastAnalyzer.kt:53)
at org.jetbrains.kotlin.codegen.optimization.boxing.PopBackwardPropagationTransformer$Transformer.transform(PopBackwardPropagationTransformer.kt:58)
at org.jetbrains.kotlin.codegen.optimization.boxing.PopBackwardPropagationTransformer.transform(PopBackwardPropagationTransformer.kt:41)
at org.jetbrains.kotlin.codegen.optimization.transformer.CompositeMethodTransformer.transform(CompositeMethodTransformer.kt:25)
at org.jetbrains.kotlin.codegen.optimization.OptimizationMethodVisitor.performTransformations(OptimizationMethodVisitor.kt:74)
at org.jetbrains.kotlin.codegen.TransformationMethodVisitor.visitEnd(TransformationMethodVisitor.kt:67)
... 43 more
Caused by: java.lang.IndexOutOfBoundsException: Cannot pop operand off an empty stack.
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.pop(Frame.java:228)
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.executeInvokeInsn(Frame.java:643)
at org.jetbrains.org.objectweb.asm.tree.analysis.Frame.execute(Frame.java:573)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeInstruction(FastAnalyzer.kt:111)
at org.jetbrains.kotlin.codegen.optimization.common.FastAnalyzer.analyzeMainLoop(FastAnalyzer.kt:74)
... 49 more
KitsuneAlex
added a commit
to karmakrafts/kotlin
that referenced
this pull request
Dec 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here is a small fix for displaying "" in "Show Structure View" action instead of empty line. Navigation to class object element works fine.