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
Creating a directory in the property getter interferes with Gradle cache
outputs snapshotting, resulting in build cache being disabled for the
task with the following info message:
Caching disabled for task ':app:kaptGenerateStubsKotlin': Gradle does
not know how file 'build/tmp/kapt3/incrementalData/main' was created
(output property 'destinationDir'). Task output caching requires exclusive
access to output paths to guarantee correctness.
As Gradle automatically creates any @OutputDirectory, we don't need
to create it at the task initialization phase.
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
TestClock.plusAssign(Duration) is for advancing TestClock time.
Hide reading value, do not allow to provide initial reading,
fix clock unit to nanoseconds at construction time.
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
This method was introduced in c204e8fc67 "just in case" and was never
used. Therefore we're free to change its semantics and use it in all new
generated code (with API version >= 1.4), without even worrying that the
newly used API will leak from inline functions in stdlib when used with
an older API version. Since we agreed to change the type of thrown
exceptions to java.lang.NPE in KT-22275, invoke a new method
throwJavaNpe now which throws that exception instead of KNPE.
Note that the additional method that takes an exception message is still
unused and exists just in case we need to use it in the future. The new
method throwJavaNpe is public also "just in case" we need to invoke it
in the future; currently it's not invoked from the bytecode.
#KT-22275 In Progress
This is required in case when NpmSimpleLinker works (instead of yarn).
NpmSimpleLinker will not produce yarn.lock file, so :kotlinNpmInstall
was always up-to-date. Adding fake state file fixes the problem.
#KT-32874 Fixed
The function was placed in a package whose another top-level function
used coroutines. This led to a NCDFE kotlin.coroutines.Continuation
with Gradle versions that bundle Kotlin pre-1.3 stdlib.
Instead, use the existing util function `lowerCamelCaseName` which also
filters nulls.
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
Fore the case where a target has been created or configured twice with different presets,
avoid showing "null" inside the error message if existing target has not preset,
and append a point.
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
Previously `validateTaskProperties` was run with tests
(`test` task depends on `validateTaskProperties` task).
Tests run with `--continue` argument on TeamCity,
so the validation was not failing remote-run builds.
To fix this, make `install` depend on `validateTaskProperties`.
Sergey Bogolepov