Getting canonical path is expensive on JDK 17, thus check, whether
file is belongs to some folder becomes expensive.
In this commit implementation was replaced to a new one based on
File.getParent. It gives profit 49seconds-> 500 ms/100k files.
Note! Now if there are present two files which are actually links of the
same file, they are treated as two different files.
#KT-54579 Fixed
Migrate KaptJavaLog to not used deprecated constructor in newer JDKs and instead set up the writers during initialization. This enables us to get rid of KaptJavaLog17.
Fixes KT-54030
Review: https://jetbrains.team/p/kt/reviews/6753
This commit doesn't fix any issue except for "cleanup". If you find a
mistake in this commit feel free to revert part of it/the whole commit
I checked every module where I drop ':dist' dependency. Tests still pass
in those modules
When counting .class files, stop once the required number is reached.
Also, implement simple counting logic directly, it is 25% faster than
using File.walk(). The way this information is used is a heuristic, so
reducing computation cost makes sense.
^KT-41456 Fixed
Because incremental KAPT tries to reuse .class files produced by kotlinc
and javac, it should check for their existence before starting
an incremental run. Otherwise, annotation processors that perform type
validation will fail to run.
Current check counts the number of declared types in processed .java
sources, and it makes sure the total number of .class files in compiled
sources dirs is equal or higher. Otherwise, KAPT runs non-incrementally.
Tests: KaptIncrementalWithIsolatingApt.testMissingKotlinOutputForcesNonIncrementalRun
^KT-41456 In Progress
When storing source information needed for type analysis, store
.java file and .class file information separately. This is because
for class files only declared typed is needed.
Tests: updating existing ones
^KT-41456 In Progress
If KAPT process is executed on latest JDKs and module
'jdk.compiler' does not export required packages, KAPT will
configure this module to export required packages.
#KT-45545 Fixed
This CL fixes a bug in KAPT's MAP_DIAGNOSTIC_LOCATIONS flag where the
location mapping for top level elements didn't work.
I also needed to changes the Kapt3IntegrationTest to copy input files,
otherwise, it cannot map file paths since the mock project has no root
location.
Cleanup tmp folders in KAPT tests, update Kapt3IT test for new lines.
^KT-47934 Fixed
Test: KotlinKapt3IntegrationTests#testErrorLocationMapping
Adds experimental feature to cache annotation processors' classloaders
It should increase speed of KAPT for consecutive runs
Works for gradle only (it stores cl in gradle daemon)
#KT-28901 Fixed
If sources contain module-info.java javac tries to validate modules existence/visibility during AP phase and fails, because we don't specify modules-path/patch-module. All these checks will be done in kotlin compiler and in javac for java classes. And it is not necessary to do it in AP too.
So we go for easiest path possible - disable jpms for AP.
#KT-32202 Fixed
See https://issuetracker.google.com/issues/162446295 for more context, but in short: this will fail if the project:
* targets java 8
* consumes external libraries targeting a higher version (java 9+). This includes Android SDK 30's android.jar, which targets java 9
* has `mapDiagnosticLocations` enabled for kapt
targetElement is a nullable type, so this seems like a pretty cut-and-dry NPE fix
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
Alexander Udalov