- implement wrappers to wrap old and new API providers and resolvers
- make old API deprecated (with error where possible)
- drop old internal classes related to the old API
- refactor usages accordingly
- fix and add missing features to the scripting API where necessary
- add a helper for new constructing Compilation Configuration only when necessary
- add more converters for legacy diagnostics
- add helpers for simpler creating of failure results
For some reason, gradle.projectsEvaluated callback evaluates after IDEA
import script gathers all project models. So, all jps related project
settings (including artifacts configurations) won't be imported.
We need only :prepare:idea-plugin evaluated. So replacing
gradle.projectsEvaluated to root Project.afterEvaluate and
forcing evaluation of :prepare:idea-plugin fixes the problem.
Adjust some error messages
Add 'fallbackElement' to report on when property is implicitly typed
Split findTypeSerializerOrContext into checked and unchecked versions
The main idea of this refactoring is to separate two usages of
`AnnotationDeserializer.resolveValue`: the one where we load annotation
argument values, and the one where we load constant values of properties
for JS/Native/Common
(`AnnotationAndConstantLoaderImpl.loadPropertyConstant`).
In the latter case, `expectedType` is the type of the property and it
can be a supertype of the actual value (e.g. see `arrayConst` in
compiler/testData/serialization/builtinsSerializer/compileTimeConstants.kt).
But in the former case, we need to check that the value conforms to the
expected type and disregard it if it's not the case, which is possible
if the annotation was recompiled separately.
#KT-28927
Artifact transform used to analyze classpath was not closing files, which
caused java.nio.file.FileSystemException. This commit fixes that, and all
input streams are closed after use.
Fixes: KT-31714
This commit changes how generated sources are added to the Gradle JavaCompile
task. Previously, directory was added to sources which caused issues with
annotation processors that only generate Kotlin sources. I.e. JavaCompile task
was executed but no java sources existed.
Now, only generated Java sources are added to the JavaCompile task. This
means that if only Kotlin sources are generated JavaCompile task will be
skipped.
Fixes: KT-31127
Test: Kapt3IT.testKotlinProcessorUsingFiler
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.
Dmitry Gridin