It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
Test data in `box/annotations/typeAnnotations` is changed because nested
classes in type annotations are rendered differently in JDK 19
(`Outer.Nested` instead of `Outer$Nested`).
#KT-54116 Fixed
This commit adds a new key that will allow users to enhance their
debugging experience in suspending contexts when using the IR backend.
After the key is enabled, the following things are changed:
1. All variables in a suspending context are spilled regardless their
liveness.
2. Their LVT records are not shrunk.
3. ACONST_NULL is not spilled to dead variables.
#KT-48678 In progress
(cherry picked from commit 38d97d0621)
This commit adds a new key that will allow users to enhance their
debugging experience in suspending contexts when using the IR backend.
After the key is enabled, the following things are changed:
1. All variables in a suspending context are spilled regardless their
liveness.
2. Their LVT records are not shrunk.
3. ACONST_NULL is not spilled to dead variables.
#KT-48678 In progress
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
Doing so speeds up psi2ir ~2 times, and thus improves total compiler
performance by about 6-8%.
Unless JVM IR is in the mode where linking via signatures is the only
way (-Xserialize-ir, -Xklib), signatures are actually not needed at all,
SymbolTable can use the frontend representation (descriptors for FE1.0,
and hopefully FIR elements for K2) as hash table keys. The only catch is
that since other backends still need to work with signatures, all the
common IR utilities, such as irTypePredicates.kt, need to work correctly
for IR elements both with signatures and without.
Also, introduce a fallback compiler flag -Xlink-via-signatures, in case
something goes wrong, to be able to troubleshoot and workaround any
issues.
#KT-48233
... and the compiler argument -Xskip-runtime-version-check.
The vast majority of warnings reported by this checker in practice has
proven to be false positives. In addition to that, it was needlessly
verbose, and also completely untested.
If we decide to reintroduce some of these checks, it's probably a better
idea to perform them in tools, such as Kotlin Gradle plugin, which
usually have slightly more information about the way the project is
built and can suggest some meaningful solutions (as opposed to "remove
this jar $HOME/.gradle/... from the classpath" which was the best
JvmRuntimeVersionsConsistencyChecker could do.)
#KT-27256 Obsolete
#KT-41664 Fixed
Instead of a Boolean flag -Xserialize-ir, use modes: none,inline,all.
In "inline" mode, only information needed to deserialize bodies of inline
functions is serialized.
In the "all" mode, all declarations are serialized completely.
It's only enabled by default in FIR and might be turned on with a CLI flag
The main idea is that default FarFS re-read ZIP file list each time when
class file is requested that is quite slow.
We read it once and them reading bytes from the known offset.
Also, unlike the default version we don't perform attributes check on each access
On the one hand, it works faster on the other it might not notice that one
of the JAR has been changed during compilation process
But looks like it's not supposed to be a frequent even during
compilation of a single module
1.fix KT-17344: Include kotlin-reflect to resulting jar if "-include-runtime" is specified, unless the -no-reflect option is specified.
2.fix KT-43220: -include-runtime should add .kotlin_builtins to the output
This flag was added a long time ago, at the time when we weren't sure if
we were going to keep the naming of local and anonymous classes
completely equal to the naming in the old backend. Now that we've
decided that we won't keep it equal and there are a lot of differences
already, it's not useful anymore.
Alexander Udalov