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.
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
The problems in JVM IR backend in these modules are fixed by:
* kapt3-cli -- 1c527fc1
* frontend -- 174b3db7
* daemon-common-new -- 6fe214d8 & d17afdda
This option has no effect on the production code. But in a custom
scenario of a local bootstrap, where the compiler is replaced with the
one where JVM IR backend is enabled by default, this option allows to
switch back to the old backend.
All of these arguments (except the one for compiling experimental
coroutines) are supposed to go away as soon as we fix related problems
in the JVM IR backend.
Lookup storage output files could differ for projects
with different absolute paths.
This happened because, paths for lookups were
relativized only before writing to the underlying storage.
Storing absolute paths in a hash table could
result in different order of adding files to the lookup storage.
This commit fixes the issue by sorting lookups and files in
LookupStorage#addAll
#KT-32674 Fixed
Pass computed list of changed classpath names to KAPT instead
of relying on the history files to be computed by stub generation.
Also, stop generating classpath history changes during the stub generation.
This commit does not compute the actual changed classpath entries,
and that will be done in the following commits.
#KT-23880
Add support for incremental annotation processors in KAPT. These
processors conform to https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing
specification.
Support is provided by using javac compiler APIs and
recording the source file structure. At runtime, processors
are instrumented with custom Filer that is used to keep track of generated
files. In order to support classpath changes, stub generation task is
used to generated a list of changed FQCNs, and this is simply used by KAPT.
Both worker and non-worker mode are supported.
#KT-23880
With gradle > 5.0 `publish()` helper call should be done before
`noDefaultJar()` or any other artifact hacks, otherwise singing plugin doesn't sign any jars
Ilya Muradyan