In the Android eco-system, there are jars with entries with a
versionNeededToExtract of 0. That should probably have been 10,
but will be hard to fix. This change proposes to just check
that the versionNeededToExtract is between 0 and 20.
To prevent OutOfMemoryError from converting the whole string to byte
array, in case the snapshot is very big (see KT-51058).
Also, remove 'framebuf' option from -Xprofile help, since async-profiler
2.0+ has unlimited frame buffer.
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
If the class `A` is in a jar `previous.jar`, the following CLI
invocation will take that class instead of the `A` class
defined in `A.java`:
kotlinc -cp previous.jar A.java B.kt
This is problematic for build tools that put the jar for a
previous build on the classpath when recompiling some of the
files.
^KT-51025 Fixed.
Previously IC state was stored in System properties. As result parallel
compilation might cause incorrect state of IC, what led to corruption
of kotlin_module files. Now IC state is stored via CompilerArguments
and CompilerConfiguration
#KT-46038 Fixed
Using the 'MULTIPLATFORM_COMPOSITE_ANALYSIS_MODE' test directive
will add support for testing "cli metadata compilation" and
"ide analysis" _like_ configurations. In this configuration,
dependsOn modules will not be analyzed together with dependents in
the same ModuleDescriptor, but will be passed as separate 'expectedBy'
dependency descriptor.
Used to cover ^KT-50120 inside kotlin.git
Java protobufs generate a lot of inner classes and when compiling
Kotlin wrappers for those Java protobufs the inner classes can
be loaded hundreds of times leading to out of memory. This change
avoids reloading by fixing a bug in the cache implementation that
caused inner classes to not be cached.
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
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
If compiler plugin removes source files between rounds of incremental
compilation, it may result into incorrect state of stubs. But rebuilding
stubs may require services available in UI mode only and cause
compiler failure.
This commit contains work-around allowing to avoid incorrect state of
stubs.
#KT-49340 Fixed
In the IDEA plugin update there are a code that used system property
"idea.plugins.compatible.build" to calculate the IDEA version
that will be sent to plugin marketplace to download last version of
the plugins. It seems like by some reason setupIdeaStandaloneExecution()
was called from the IDEA thread and because of that idea version was
calculated incorrectly and incorrect version of the plugins was
downloaded.
It is still unclear how the setupIdeaStandaloneExecution() could be
called from the IDEA, so added logging for that.
Relevant issue: MP-3702
Relevant code in the IDEA:
- ApplicationInfoImpl.getPluginsCompatibleBuildAsNumber
Previous episode was at 987a3460 (KT-45915).
Apparently, it's not enough to run psi2ir for all modules, and then
backend for all modules. If there are several modules in the chunk, IR
in any one of them can reference IR of any other one after psi2ir.
So we would end up in a situation where we're running codegen for the
first module, but the second module is completely unlowered. This would
break some assumptions in the codegen, for example in KT-49575, codegen
would see a reference to a top-level function from another module, and
would fail because the function has no containing class (since file
facades have not been generated yet!), and thus must be an intrinsic,
yet no such intrinsic is known to the codegen.
The solution is to run lowerings first on all modules, and then run
codegen on all modules. The kind of error explained above shouldn't be
possible anymore, because lowerings have to deal both with lowered and
unlowered code from other files all the time, so lowerings can't assume
that reference from other module is lowered either (or unlowered).
The code is not very nice, but hopefully it can be improved as soon as
we get rid of the old JVM backend (and maybe later with the migration to
FIR too).
#KT-49575 Fixed
The kdocs were almost self-evident, as opposed to the fact that
JvmClasspathRoot is unused in the project, which could make it a victim
of an innocent refactoring.
... 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
Victor Petukhov