Currently, KAPT3 uses JDK internal API to build Java AST.
Since the API is internal, it has changed in newer JDKs.
So, for them, use reflection to access new API.
#KT-59349 Fixed
This change expanded KAPT to support a new param
'fileAccessHistoryReportFile', which reports all the classes used during
annotation processing into a file, in the form of a list of URIs.
This is useful for build speed improvements described in https://engineering.fb.com/2017/11/09/android/rethinking-android-app-compilation-with-buck/.
Essentially, using the list of used classes, we can compile only
the dependencies that are really affected by the developer's
code changes and improve Kotlin build speed.
^KT-52853
- make some utility functions and classes public
- split some classes into common and Kapt 3 - specific parts
- use Kapt 4-ready filtering of @Metadata annotations in tests
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.
strangepleasures