Fix for KT-1334 Class object in "Show Structure View" action

Corrections/Suggestions in the first section

…tClass

Diagnosing KT-12966

…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?>())
```

…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?>())

…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?>())

Own tests on Constant Propagation created. This closes #1

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.

sync with upstream

[FIR] Fix FIR2IR Types on SetVariable Expressions

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.

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.

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.

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.

That code is convoluted, better take it slow to avoid accidentally
breaking (or fixing) anything.

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

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

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

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

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

…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)

…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)

…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)

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

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

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

* Add 0 to allowed package name characters (JetBrains#1)

For some unknown reason, `0` is the only alphanumeric character that wasn't recognized as in a package name. This led to odd scenarios that when you tried to compile code that had a `0` in the package name, the kotlin builder would package the code as the string before the `0` which led to some problems in auto-generated code.

* Add Test

* Fix missing colon

Co-authored-by: justhecuke <justhecuke@gmail.com>

…iagnostics

#KT-80049 Fixed

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…iagnostics

#KT-80049 Fixed

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics

…n> to diagnostics