Previously, even if `keepKdocComments=false`, we would still create the
KDocCommentKeeper object unnecessarily.
This commit makes sure we create the object only if
`keepKdocComments=true`.
Bug: Clean-up after commit e252171 for KT-43593
Test: Existing tests
Currently, KaptGenerateStubsTask may not generate KDoc comments
correctly. See KT-43593 for more details.
This commit provides a Kapt flag called
`kapt.keep.kdoc.comments.in.stubs`
to control whether KDoc comments will be included in the generated
stubs.
This flag is currently enabled by default to keep the existing behavior
and avoid breaking existing users.
Users who don't need KDoc comments in stubs but are hitting KT-43593 can
disable the flag.
Whether this flag will be disabled by default later is to be determined.
Bug: https://youtrack.jetbrains.com/issue/KT-43593
(Note that this commit only provides a workaround, it doesn't
actually fix the bug.)
Test: (Ir)ClassFileToSourceStubConverterTestGenerated#testCommentsRemoved
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
Add integration test which checks if only types can be
reprocessed in an incremental round. Also, remove unused
`invalidateTypesForFiles` method.
Furthermore, clarify that types that are reprocessed
(i.e types from .class files) are not necessarily
aggregating types, but simply types that should be reprocessed.
Test: KaptIncrementalWithIsolatingApt.testClasspathChangesCauseTypesToBeReprocessed
This change introduces tracking of generated sources structure in order
to e.g track classpath changes impacting generated sources. This fixes KT-42182.
Also, origin tracking for isolating processors is now using types, allowing
for origin elements from classpath. This fixes KT-34340. However, classpath
origin is used only to invalidate generated files when the type changes and
processing will not be requested for that type. This is in line with the
incap spec.
KAPT was relying on clearing JarFileFactory to make sure
annotation processing does not hold onto annotation processing
classpath once done. Once KAPT switched to using Gradle workers, multiple
KAPT runs were sharing the same class loader ie. the same version
of JarFileFactory. Clearing the cache resulted in race condition,
as some runs were unable to load processors from jars.
This commit fixes this problem by avoiding the use of ServiceLoader
which was causing the issue. Jars would be added to the cache, but
they would never be removed. That's why JarFileFactory had to be
clearned manually. By loading the processor names manually (simply
exploring the classpath), no file handles leak.
Fixes https://youtrack.jetbrains.com/issue/KT-34604
Test: verified against the test project from the bug
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
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.
When instantiating annotation processors, the class loader where they
are defined needs to have the correct parent class loader set up. In
order to find the parent class loader, we need to find the most specific
class loader that contains javac compiler classes (and does not contain
e.g. KAPT classes). This commit changes how that search is done, and it
simply returns the class loader in which the com.sun.tools.javac.util.Context
is defined, as the is the class we need on the annotation processor
classpath.
This commit fixes KT-33028 by not setting empty boot classpath when
running on JDK9+. When compiling with -source 8 and below, this allows
classes from java.base module to be available in the boot classpath.
This commit also fixes KT-33050 by passing the source level of Java compile
task in the KAPT javac options. This is important as some annotation processors
are using ProcessingEnvironment.getSourceVersion() in order to decide what
code to generate.
Test: Kapt3IT test added for worker and non-worker invocations
This commit fixes an issue when all APs would be reported as non-incremental,
even if only a single one is non-incremental. Now, additional declared type
is added that is used to denote processors that are incremental, but have
been forced to run non-incrementally in presence of non-incremental APs.
This means that only APs that do not support incremental annotation processing,
or APs that are dynamic and are non-incremental at runtime will be reported.
This commit improves incremental KAPT logging. It reports processor
stats using their actual names. Also, warning is printed if incremental
annotation processing is requested, but not all APs are incremental
KaptFlag.INCREMENTAL_APT is used to indicate that KAPT run
should try to be incremental because changes to input files and
classpath have been detected. However, first run of the Gradle
task will set this flag to false, which means that all APs will be
detected as non-incremental in the first run. Further on, this means
that the dependency caches will be invalid, and all subsequent runs
will be non-incremental as well.
This commit uses existence of dependency cache to determine if incremental
APs should be discovered. The regression was introduced in
72fdc648ff.
Test: ./gradlew :kotlin-gradle-plugin-integration-tests:testAdvanceGradleVersion --tests *KaptIncrementalWith*\
&& ./gradlew :kotlin-gradle-plugin-integration-tests:test --tests *KaptIncrementalWith*
It is possible for isolating annotation processor to report two or more
originating elements from the same source file when generating
sources/classes/resources. This commit makes sure the source file are
de-duped, so assertion that there is a single source file does not fail.
Test: IsolatingIncrementalProcessorsTest.testIsolatingWithMultipleOriginatingElements
This is improvement to https://youtrack.jetbrains.com/issue/KT-23880
When analyzing source files in KAPT for incremental annotation processing,
avoid creating TreePath instances for initializers that are literals. E.g.
if it is just a boolean/int literal, we do not need to visit the tree nor
create expensive TreePath instance.
For classes that contain only constants (such as R.java for Android projects)
this is a significant improvement. Class that contains 16000 constants took
more than 10 seconds to analyze, now it is 70ms.
When incremental apt mode in KAPT is disabled, do not analyze
classpath to determine the type of the annotation processors. Instead,
just mark them all as non-incremental.
When running incremental annotation processing in KAPT,
even if incremental flag is enabled, and full rebuild should
be performed (e.g. in presence of dynamic non-incremental APs),
make sure generated sources and classes are removed.
#KT-31322 fixed
There is no need to track definitions of constants in sources for now.
References to constants are tracked in order to capture dependencies between types.
This ensures that any change to a type defining a constant (either from the
classpath or sources), will trigger reprocessing of the type that uses the
constant.
1) Fix tests to use canonical path for comparison because Mac was failing
2) Update current classpath snapshot only with the missing entries from the previous one
3) Clean-up code and style
Use artifact transforms to capture structure and
dependencies of classpath entries. In the KAPT task
this information is used to compare previous classpath
structure with the current one. Once changed classes are
detected, all classes that transitively depend on those
are identified, and that set is passed to KAPT invocation.
In order to avoid unrelated classpath changes, we record an
ABI snapshot of the classpath entry. This snapshot ignores
all private members, and @Metadata annotation.
#KT-23880
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
This commit adds support for tracking of used constants in
source files. For every constant used in a source file, class
that defines the constant and the constant name are tracked.
Value of the constant can be obtained using
annotation processing APIs, so if the constant value changes, a source file
using it has to be reprocessed.
#KT-23880
Hung Nguyen