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.
Put initializers on fields when corresponding primary constructor
parameters have a default value specified. The new behavior
is available under the new 'DUMP_DEFAULT_PARAMETER_VALUES' flag.
Note that this doesn't affect regular functions with default parameter
values, as well as primary constructor parameters without a
'val' or 'var' keyword.
tools.jar from JDK has different public api on different platforms which
makes impossible to reuse caches for tasks which depend on it. Since we
can't compile against those classes & stay cross-platform anyway, we
may just exclude them from compile classpath. This should make tools.jar
compatible at least within one build of JDK for different platforms
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.
When running KAPT incrementally, make sure to pass error/NonExistentClass.java
when there is at least one source file to process. This is to make sure
APs that must resolve all types are able to do so.
Test: updated KaptIncrementalWithAggregating/WithIsolating
Isolating incremental AP must report exactly one originating source file.
This commit logs a warning when this constraint is violated.
Test: AnnotationProcessorDependencyCollectorTest.testIsolatingWithoutOrigin
JDK9 may decide to load .java files from jar when resolving a type, even
when .class file exists in the same jar. Further on, these files will be
parsed and analyzed, which triggers the listener used by incremental
annotation processing. This commit avoids analyzing those files, and
makes sure URI passed from the compiler are such that a File instance
can be created.
Test: KaptIncrementalWithIsolatingApt.testSourcesInCompileClasspathJars
This class does not exist in JDK9, so running incremental KAPT on
JDK9 fails. Because it is used only to get the name of the file,
this has been replaced with usage of the public JavaFileObject API.
Avoid using JavacProcessingEnvironment.validImportStringToPattern method
because it has been removed in JDK9. This commit changes how we compute
pattern to match the class names, and it create instances of Pattern
manually by following spec for Processor.getSupportedAnnotationTypes().
Support for module prefix is not added yet.
When using JDK11, generating stubs for enums is broken.
This commit handles the faulty generation by JDK11 by
fully printing enums in custom implementation of tree
printing.
Test: added JDK11 tests for KAPT stub generation
When KAPT is unable to run incrementally make sure to
clean directory that contains generated Kotlin sources.
This location is specified using '-Akapt.kotlin.generated'
option.
Mikhail Bogdanov