Stack Trace
at kotlin.collections.CollectionsKt___CollectionsKt.first(_Collections.kt:184)
at com.intellij.configurationStore.XmlSerializer.<clinit>(xmlSerializer.kt:15)
at com.intellij.codeInsight.CodeInsightSettings.writeExternal(CodeInsightSettings.java:228)
at com.intellij.testFramework.UsefulTestCase.<clinit>(UsefulTestCase.java:104)
at com.intellij.testFramework.TestLoggerFactory.log(TestLoggerFactory.java:154)
at com.intellij.testFramework.TestLogger.info(TestLogger.java:70)
at org.jetbrains.kotlin.scripting.compiler.plugin.definitions.CliScriptDependenciesProvider.calculateRefinedConfiguration(CliScriptDependenciesProvider.kt:45)
...
Since we now generate file classes even for IR loaded from dependencies
(see 3a9b94235f) to simplify code in certain lowerings, it makes sense
to do that for all source files together before any meaningful
lowerings. The easiest way to do so is to make FileClassLowering a
module-wide phase.
ExpectDeclarationsRemoveLowering is now also a module-wide phase because
it needs to be run before FileClassLowering (to avoid producing empty
facades for files that only contain `expect` declarations)
Similarly to how it's done for callable references. This is needed for
IrTypeMapper to be able to correctly compute the name of the SAM wrapper
IrClass without resorting to the name of the underlying descriptor
(computed in CodegenAnnotatingVisitor)
This is useful to store data that must be kept when the element is
transformed, such as names of local/anonymous classes and
EnclosingMethod values on JVM which are computed before any lowerings.
For now, this is implemented very conservatively: the only field
`attributeOwnerId` which can be used in BackendContext implementation as
a key in the map
last-exclusive progressions (i.e., "until" progressions and loop over
array indices).
This change makes it possible to correctly implement the handling of
"step" progressions. Computing the last element of a stepped progression
requires that the last is inclusive.
Also invert the while loop (into if + do-while) that is used when
lowering for-loops over progressions that cannot overflow. This keeps
the performance characteristics closer to the ForLoopsLowering in
kotlin-native, since the goal is to converge to this shared version.
Also used IrType instead of KotlinType, where possible.
https://github.com/JetBrains/kotlin/pull/2390https://github.com/JetBrains/kotlin/pull/2305
Unfortunately this cannot currently be done for the extension overload which accepts a radix due to behavior difference with regard to invalid radix values.
victor.petukhov