Otherwise IC fails when a project declares a class with the same name
as in one of its dependencies.
The issue is relevant only for non-JPS IC (Gradle, Maven, etc.),
but I added the test for JPS too.
#KT-20516 fixed
In some cases IC needs to perform a rebuild.
Before this change IC was not clearing output directories
besides destination dir for classes, so for example
kapt stubs were not cleared.
Stalled stubs might lead to compile errors.
For example:
1. foo/XGen.java is generated from annotated class foo/X (XGen also
references X).
2. foo/X is moved to bar/X and some other change forces IC to rebuild.
3. kapt generates bar/X stub, but foo/X stub
was not removed because stubs dir is not cleared.
4. kapt runs annotation processors, foo/XGen.java is generated from
foo/X stub, bar/XGen.java is generated from bar/X stub.
5. kotlinc rebuilds. Since destination dir is cleared properly,
only bar/X.class exists.
6. javac tries to compile foo/XGen and fails, because it
compiles against actual Kotlin classes, not stubs.
This commit fixes the issue by passing all output directories
of a task from Gradle to Kotlin IC.
#KT-21735 fixed
Remove a non-reflective usage of the ResourceSet class, which has been
moved to a different package between versions. Access it through
reflection instead. This is a workaround. We can introduce a proper
fix once we have a public API in the Android plugin.
The test case that could detect the compatibility issue is
`testAndroidExtensionsManyVariants` (it uses experimental Android
extensions), but we did not run it with 3.2.0-alpha6. This commit
adds a test class with the same tests for 3.2.0-alpha6.
Issue #KT-23192 Fixed
Placing location table inside .java file triggers annotation processor to run on each line table modification (even when the stub declarations themselves are the same). So we move it to the separate file.
Store kapt configurations instead of classpath files in the tasks
Delay wrapping kapt subplugin options to task execution (when the
classpath can be safely resovled)
Issue #KT-18821 Fixed
This fixes `VerifyError` for all integration tests calling
`KotlinTestUtils.findAndroidSdk()`.
The exception was thrown because `:kotlin-gradle-plugin-integration-tests`
was depending on both relocated intellij-core (from kotlin-compiler-embeddable)
and non-relocated intellij-core (transitevely through tests jars from compiler).
A call to `findAndroidSdk()` was triggering classloading
for `KotlinTestUtils` which had bytecode references to
`org.jetbrains.kotlin.idea.KotlinLanguage` loaded from the embeddable compiler
and to `com.intellij.lang.Language` loaded from non-relocated intellij-core.
`KotlinLanguage` from the embeddable compiler was a subclass of relocated
`org.jetbrains.kotlin.com.intellij.lang.Language` thus it was not
assignable to `com.intellij.lang.Language` causing `VerifyError`.
The solution is to create relocated jar combining the necessary test jars
from the compiler.
A test task, that uses android dependency but does not depend on
a corresponding configuration, would fail when it was run after
'clean' task.
I've extracted 'useAndroidSdk', 'useAndroidJar' extensions
making it harder for a developer to forget to set up task dependencies.
*.kjsm and other files might be received when FileCollection is
used in Gradle as a dependency.
Example: `testCompile project(":$coroutines_core").sourceSets.test.output`
(a popular-ish solution to introduce dependencies between tests)
Add 'kotlin.caching.enabled' flag to switch the caching for all tasks;
Rename and change semantics of cache support checks: make two instead
of one, `isBuildCacheSupported` and `isBuildCacheEnabledForKotlin`;
Remove FileOptionKind entries that are redundant at the moment;
Improvements in BuildCacheIT.kt and other refactoring suggestions from
the review
https://upsource.jetbrains.com/kotlin/review/KOTLIN-CR-1647
Yan Zhulanow