FirExtensionRegistrar is FIR specific extension which requires FIR
classes to work, which are missing in dependencies of FE 1.0 IDE plugin.
To fix this issue FirExtensionRegistrarAdapter is introduced. This
class is a base class for FirExtensionRegistrar and it does not have
any FIR specific classes in it's API, so it can be safely registered
in IDE
... 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.
This is an internal compiler argument for FIR which doesn't seem
valuable enough to be exposed in Gradle, because it'd require to perform
some kind of deprecation if it's changed or removed. It'll still be
possible to use it via `freeCompilerArgs += "-Xbuiltins-from-sources"`.
Note that generated Gradle options are not changed because the generator
was not rerun after adding this compiler argument. (And the test that
checks that the generator was run is failing right now.)
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
Roman Artemev