Move it to build-common where it's still used in incremental compilation
caches, and simplify a bit. In the future, it'll make sense to remove it
completely and to avoid writing it to caches. In this commit, I don't do
that to prevent the IC cache version to be updated, causing rebuilds for
all JPS projects.
#KT-41758
Support use-cases when the build dir is outside of root project dir.
Many projects set up output dir as <root_project>/../out/<project_name>/build
to be able to clean build dir more easily. This commit adds support
to build history file detection and it tries to find build history
files for artifacts that are:
- under root project dir (a default structure)
- under root project's build dir parent (to support typical custom setup)
Fixes https://youtrack.jetbrains.com/issue/KT-40875
Test: BaseIncrementalCompilationMultiProjectIT
Multifile facades (class files with header kind MULTIFILE_CLASS) have
the list of their parts in the d1 field (KotlinClassHeader.data), not
some byte-encoded protobuf message which this code was trying to
deserialize previously.
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
IC caches could be modified and read from different threads.
In JPS builder these threads are RMI worker (invoked from Compiler
Daemon) and JPS worker thread. Proper synchronization fixes cases
when caches could become broken.
#KT-42265 Fixed
#KT-42194 Fixed
#KT-42265 Fixed
#KT-42937 Fixed
Supported case then children of sealed classes could be declared
anywhere in a module. If list of classes implementing sealing class
changes the sealed class and all its inheritors should be recompiled
(now sealed class should be compiled together with children in order
to calculate all possible inheritors at compile time) and and
invalidated (as they could have when operators).
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.
A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
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
This allows to replace dependency on 'js.frontend' with 'js.config', in
'kotlin-build-common' and 'daemon-common'. Also simplify some other
dependencies.
- Remove klib dependency on metadata and uniqID
- Refactored proto format to make it more effective and compact
-- Use special encoding for some types of data (coordinates, flags, types)
-- Remove symbols table
-- Use packed proto list if it is possible
- Remove extension from metadata
- Remove special ids for function interfaces
- Fix klib IO
- Fix incremental cache
- General code clean up
Sometimes IC raises compilation errors when rebuild succeeds.
This happens because IC uses serialized decriptors
for non-dirty files. Serialized descriptors can be different
from source file descriptors. For example, a source file
may contain an implicit return type or an implicit visibility
for overridden methods, but serialized descriptors always
contain explicit return types & methods' visibilities.
These problems can be solved by expanding a scope of incremental compilation
just after the analysis, but before error reporting & code generation.
In other words, we need to compare descriptors before error reporting and code generation.
If there are new dirty files, current round of IC must be aborted,
next round must be performed with new dirty files.
This commit implements IC scope expansion for JS Klib compiler
#KT-13677
#KT-28233
Alexander Udalov