Also remove these option providers from the javac task compiler argument
providers so as to avoid output intersections of javac vs kapt.
The options generated by the providers are added to the Kapt subplugin
options as well in order to be passed to Kapt. Since these options
are a list, not a map, pass them without name (Kapt should decode them
into plain arguments). Remove the '-A' prefix as it is there for
command line annotation processor options, but we don't need it, it
is added by Kapt internally.
Issue #KT-23964 Fixed
Issue #KT-24420 Fixed
Previously some Kotlin files were recompiled, because Java files
were regenerated.
However this is no longer true for some time since
precise Java tracking was implemented.
Adds Gradle test for the exception:
`java.lang.ClassNotFoundException: net.jpountz.lz4.LZ4Factory`
The exception breaks IC in Gradle. Gradle compiles non-incrementally as
a fallback strategy, so the build succeeds, but IC is not working.
IC uses persistent hash tables from Intellij as caches.
These tables's buffers are compressed when full.
Previously snappy was used for compression, but 181 platform switched to
LZ4, which was cut out by proguard.
The problem could only be reproduced with Gradle,
since in JPS plugin all caches are managed by JPS process,
which contains the necessary library.
To reproduce the compiler needs to be processed by proguard
(which always happens on TeamCity).
Many classes are needed to trigger the compression.
Since Android considers the `compile` configuration as deprecated and
reports a warning when a dependency is added to it, use the `api`
configuration when dealing with an Android platform module.
Issue #KT-23719 Fixed
This addresses the cases when a module name contains a slash
(e.g. when the Gradle project name was set this way to point
Gradle to the directory), which led to Kotlin module file being placed
under a subdirectory of META-INF and thus undiscoverable for the
compiler and reflect.
Additionally, this fix removes characters \n, \r, \t whose
presence in a module name caused compilation failures.
Issue #KT-20608 Fixed
KaptTask was not declaring the compiler classpath (which it takes from
compileKotlin task for calling the compiler) as input. This commit fixes
that and adds a test that checks compiler classpath input checks for the
kapt tasks.
Issue #KT-23879 Fixed
Since the custom source sets may be added after the plugins are applied in both common and platform module, we need to handle `.all { ... }` source sets in both modules and add common sources to the platform module once a match is found.
Issue #KT-22510 Fixed
When the JavaCompile tasks were removed from a common project, some of
the dependencies on them remained. This could lead to an error during
dependencies resolution, such as the one in KT-23092. To an even greater
confusion, the remaining dependencies anyway led to the task being
added to the task graph.
Issue #KT-23092 Fixed
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
Alexey Tsvetkov