Given that the Kapt subplugin creates new tasks, it is impossible
to run it in the context of lazy task configuration. Disable lazy
task configuration for Kotlin/JVM by always accessing the task
instance until subplugins are refactored to be able to properly
work with task configuration avoidance.
Replace the old ad-hoc task matching mechanism used for connecting the
compilation tasks that need to share internal visibility with an
implementation based on the associate compilations and compilation
outputs rather than `destinationDir`s of the tasks.
The only place that still requires ad-hoc friend paths is the Android
instrumented tests compiling against the JAR of the main variant, not
its classes dirs. Support that with `friendArtifacts`.
Issue #KT-17630 Fixed
Issue #KT-20760 Fixed
Add test for aggregating incremental annotation processors and JDK9.
This makes sure the implementation is not using any types that have
been removed in JDK 9.
Fix test failure on Windows, where backslash was not escaped
in a build file. Also, remove obsolete test for Gradle 4.2,
because 4.3 is the minimum supported version.
Earlier, K/N 1.1 was used when testing the kotlin.native.version
property. But this version doesn't support the -no-endorsed-libs
flag add recently. This patch updates K/N version in tests.
When analyzing incremental changes in the KAPT task, incremental compilation
can handle directory changes, Java source file changes, jar/.class file changes,
and changes to the ABI structure of the classpath. Anything else should cause
a full recompilation.
Test: KaptIncrementalWithIsolatingApt.testNonIncrementalWithUnrecognizedInputs
The free args DSL may be changed in 1.3.70 for all platforms. So it
was decided to preserve the old behaviour here to avoid making
similar changes in two releases in a row.
We leave an ability to build final native binaries directly from
sources instead of building them from a klib. Thus we allow
a user to workaround possible bugs related to building a final
binary from a klib (-Xinclude compiler flag).
Earlier we propagated all free args specified for a compilation into
a link task. It was required because the link task actually compiled
the same source as the compile task but with another output kind.
But currently a link task produces a final binary from a klib instead
of sources. It means that such a propagation becomes incorrect. Now
options related to the compiler frontend like -Xexperimental must
be specified per compilation while options related to the compiler
backend (e.g. -opt, -g, -Xstatic-framework etc) - per binary.
This path shows a special warning if some of "binary-specific"
arguments are passed to a compilation.
Earlier all native binaries were produced directly from sources of
corresponding compilations. This patch changes this behavior. Now
a klibrary produced by a compilation is used to build a final
binary instead of sources. This allows us to avoid parsing the same
sources several times and reduces build time.
This patch also updates K/N version to 1.3.60-dev-11975, to get the
corresponding support from the compiler side.
Issue #KT-33076 Fixed
This commit fixes KT-33028 by not setting empty boot classpath when
running on JDK9+. When compiling with -source 8 and below, this allows
classes from java.base module to be available in the boot classpath.
This commit also fixes KT-33050 by passing the source level of Java compile
task in the KAPT javac options. This is important as some annotation processors
are using ProcessingEnvironment.getSourceVersion() in order to decide what
code to generate.
Test: Kapt3IT test added for worker and non-worker invocations
Refactor: move some properties from the Kotlin tasks to the
new task data model, so they can be accessed without forcing the
tasks to instantiate.
Don't iterate over Kotlin tasks of all projects in the IC-related code;
instead, inspect the model.
Issue #KT-31713 Fixed
Annotation processor classpath for a KAPT run is recorded, and the current
run is compared against the previous one. If those differ, KAPT should
run non-incrementally.
Test: KaptIncrementalWithIsolatingApt.testChangingAnnotationProcessorClasspath
When comparing previous and current classpath snapshots, and it is not
possible to compute the types that changed, make sure to delete the outputs
before invoking KAPT.
Test: KaptIncrementalWithAggregatingApt.testIncompatibleClasspathChanges
Replace iteration over all tasks with `.matching { ... }` with `
.configureEach { if (...) ... }`, so that the check iterates
just over those tasks which are triggered to configure from
somewhere else.
Issue #KT-31666 Fixed
Test processes themselves don't do much
(RAM heavy work is done in Kotlin and Gradle daemons).
The default 1600m max heap size is unreasonably high
for copying test projects and checking output logs.
Android Gradle Plugin 3.0 and 3.1 use aapt that does not handle
long paths on Windows. This commit uses shorter paths for the project
working directory on Windows.
Test: running integration tests on Windows
The test is not designed to fail if the definitions are not discovered -
the script files have completely custom extensions and therefore ignored.
So checking for the warning in the build log is enough.
#KT-32697 fixed
Artifact transform that uses ASM to analyze KAPT classpath stored absolute
paths in the output artifact. This resulted in remote build cache misses.
This commit changes how analysis is stored. Actual analysis file is the
output of the transform, and there is not need to use a marker file any more.
Output does not store the classpath entry absolute path. Instead, it uses
task action incremental information to find analysis outputs that changed.
Additionally, class that handles analysis snapshot comparison has been
simplified, and lazy loading of the structural information is handled in
a more straightforward way.
Fix dependencies that are added in non-published source sets, which were
omitted from the requested dependencies since their configurations were
not added to the extendsFrom set of the merged configurations.
Also, don't resolve both merged configurations (compile and runtime) in
GranularMetadataTransformation, as the IDE can anyway import only the
compile-scoped dependencies from api & implementation.
Issue #KT-32225 Fixed
Fix incorrect source sets visibility when a dependency is added to a
non-root source set and its visible source sets are mistakenly treated
as already visible by the dependsOn parents and are thus not extracted
from the metadata package.
To simplify the logic, reuse the GranularMetadataTransformation
instances from the dependsOn parent source sets: they can provide the
requested dependencies sets for the parents and their transformation
results, so that excluding the dependency source sets which are seen
the parents gets simpler.
The issue is then fixed by naturally excluding only the source sets
which are mentioned in the parents' transformation results.
Issue #KT-32204 Fixed
Ilya Chernikov