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.
KotlinBuild
pushed a commit
that referenced
this pull request
May 15, 2023
The reason #1 for this feature is that we want to test IdSignatures generated for declarations. Currently, there is no (easy) way to ensure that a change in the signature building logic doesn't cause any breaking changes wrt klibs. Now, most IdSignatures include hashed mangled names in them, so even if we catch a regression where the included hash changes, there would be no way of knowing immediately what caused it, unless we'd also have mangled names in the expectations. The reason #2 is to test the manglers themselves. Currently, there are no tests for them. They heavily duplicate each other, this is already causing issues (see KT-57427) that would be very hard to catch without these tests. ^KT-58238 Fixed
EgorKulikov
pushed a commit
that referenced
this pull request
May 16, 2023
The reason #1 for this feature is that we want to test IdSignatures generated for declarations. Currently, there is no (easy) way to ensure that a change in the signature building logic doesn't cause any breaking changes wrt klibs. Now, most IdSignatures include hashed mangled names in them, so even if we catch a regression where the included hash changes, there would be no way of knowing immediately what caused it, unless we'd also have mangled names in the expectations. The reason #2 is to test the manglers themselves. Currently, there are no tests for them. They heavily duplicate each other, this is already causing issues (see KT-57427) that would be very hard to catch without these tests. ^KT-58238 Fixed
bnorm
added a commit
that referenced
this pull request
Nov 17, 2023
Write service info from annotation processor
KotlinBuild
pushed a commit
that referenced
this pull request
Nov 28, 2023
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)
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.