This fixes an issue in constructing annotation instances with array
class elements. For some reason, behavior of `ClassLoader.loadClass`
differs from `Class.forName` in handling arrays, namely:
* `loadClass("[Ltest.Foo;")` returns null
* `Class.forName("[Ltest.Foo;")` returns class for array of test.Foo
Overall, there doesn't seem to be any way to load an array class with
`CLassLoader.loadClass`.
We pass initialize=false to forName because this is the behavior of
ClassLoader.loadClass: it doesn't perform class initialization (e.g.
<clinit> is not executed).
#KT-31318 Fixed
Before this commit, getTextOffset() and getTextRange() coming from the super class, returned numbers for the property, not for its accessor. This commit fixes the inconsistency.
Context for determine if a value parameter is captured from outer
context is not directly available after lowering, hence introduce a new
IrDeclarationOrigin for captured receiver parameter to avoid duplicate
calculation.
Candidate ordering should be the same in ordinary Kotlin code and in evaluated expressions.
With the invention of 'foo_field' syntax, there is no need to do these nasty things any more.
In case the wrapped exception message contains some long text (bytecode,
IR, etc.), it could be displayed several times in the same stack trace,
which significantly worsened the experience of parsing such stack traces
This reverts commit 674badc6
Since idea 192.5587.17 idea has own InjectedLanguageManager registration
and fails because of duplicate.
org.junit.ComparisonFailure: exception: org.picocontainer.defaults.DuplicateComponentKeyRegistrationException: Key com.intellij.lang.injection.InjectedLanguageManager duplicated
at com.intellij.util.pico.DefaultPicoContainer.registerComponent(DefaultPicoContainer.java:123)
at com.intellij.util.pico.DefaultPicoContainer.registerComponentInstance(DefaultPicoContainer.java:331)
at com.intellij.mock.MockComponentManager.registerService(MockComponentManager.java:89)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.registerJavaPsiFacade(KotlinCoreEnvironment.kt:162)
at com.intellij.core.JavaCoreProjectEnvironment.<init>(JavaCoreProjectEnvironment.java:55)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreProjectEnvironment.<init>(KotlinCoreProjectEnvironment.kt:27)
...
Building on the work in #2403, shaves 1% of compilation time on kotlinx.serialization
by using SmartIdentityTable instead of hashMap in LabelNormailizationMethodTransformer.
Metrics on the prior hashMap use in this code:
| What | Count |
| --------- | ----- |
| instances | 21530 |
| min | 0 |
| max | 174 |
| mean | 4 |
| stddev | 8.24 |
| median | 4 |
| 90p | 8 |
| 95p | 15 |
Multiple IrType extensions were incorrectly calling isNameInPackage
which actually checked if the name of the type's classifier _starts_
with the given string, not equals it. Move them to irTypePredicates,
which seems a more natural place for these extensions anyway. Move
isKClassArray to JVM backend utilities, since this is JVM-specific
behavior at the moment. Fix minor warnings/inspections
Alexander Udalov