Test failure was caused by "replace custom source root types to a special
'unknown' type and back on plugin unload/load (IDEA-235292)" in intellij.
We override `getModuleSourceRootPropertiesSerializers` in `KotlinModelSerializerService`
by inheriting from `KotlinCommonJpsModelSerializerExtension`
Original commit: 6985c5fd2a
Otherwise they are detected as common source-sets, thus getting
K2MetadataCompilerArguments (instead of FakeK2NativeCompilerArguments),
and the 'applyCompilerArgumentsToFacets' will fail due to check on
javaClass equality
^KT-39657 Fixed
Original commit: 5b48845dfa
The CompilerMessageLocation is an implicit part of the binary daemon
protocol so changing it breaks compatibility with older daemons.
This change allows to extend location for non-daemon uses without
breaking the binary protocol.
Original commit: 5e33612238
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
Original commit: 012ffa2993
JPS does not remove output files for files marked as dirty
for current iteration. This is a problem for adding complementary files
during JPS MPP IC.
If output files are not removed, the compiler might raise an error
for duplicated actual declarations.
Original commit: 06275a201c
Previously IC could go to the next iteration without removing
outputs for the files compiled during the last iteration.
For example, it could happen, when a multifile part is changed
(we add sources for other parts and recompile everything together).
In case of MPP it could lead to compile error, because
the compiler would see the same actual declarations from dirty sources
and dirty outputs from previous iteration (which should have been removed).
That behaviour did not raise an error before a5c976d0f751830704daa8b7386fcc288139c35c
because actual declarations from binaries (e.g. compile classpath) were ignored.
#KT-35957 Fixed
Original commit: 4ccec5218f
This fixes the weird cases when a class gets overwritten by an imperfect
copy, reduces the number of classes in the output if an inline function
contains an inline call that causes it to have regenerated anonymous
objects, and makes inlining of same module functions a bit faster in
general. On the other hand, this may increase memory footprint a bit
because classes cannot be flushed to the output jar, as the inliner
would not be able to locate classes for anonymous objects if they have
already been unloaded from memory.
Original commit: 82899e6243
Different line endings on linux/windows prevents gradle from reusing
build cache since endings make task inputs completely different between
systems
Original commit: bcefa68df0
The problem here is that library resolver uses global project compiler
settings instead of the module ones. That behaviour is caused by more
global problem described in #KT-21246
As a temporary solution we just do not show IR_COMPILED_CLASS error in
IDE if it arises in a module which have -XuseIR or
-Xallow-jvm-ir-dependencies option provided
#KT-36907 fixed
Original commit: 97e320b57f
Bug fix `NoConstantValueAttributeForNonConstVals` removes constant attribute from non-constant properties.
Code using such properties does not have to be recompiled, since its value is no longer inlined.
Original commit: 6ed1cc5cd8
Ilya Gorbunov