Currently the test makes more harm than use:
* It is too slow: two executions (with different Gradle versions)
take 5 minute on CI.
* It is unreliable: the test fails on CI for months
with insignificant violation of the memory growth limit.
After this change:
* the memory growth limit is increased;
* the test run count is decreased;
* changes the test to use separate project with minimal amount of classes
(we're not interested in compiler's memory leaks; only Gradle plugin specific ones);
We run all tests with multiple Gradle versions now,
so parametrized test is not needed anymore.
Test cases are moved to relevant test classes.
testKaptProcessorPath is removed because kapt1 is not supported anymore.
Encapsulate daemon run count within DaemonRegistry to simplify reasoning
about the state.
Never count test process Gradle version as active Gradle process.
Fix the bug when daemon version hit max run count threshold
would be restarted every time after that.
Otherwise the test `KotlinAndroid32GradleIT.testIncrementalCompile`
failed with Android resource linking failed error:
"attribute 'package' in <manifest> tag is not a valid Android package name: 'foo'."
Bound references require kotlin-reflect 1.1.x on runtime.
However old Gradle versions (e.g. 3.4) can leak 1.0.x reflect
into Gradle classloader, so getting bound reference fails on runtime
(in this case the plugin couldn't connect to the daemon).
Previous plugin resolution mechanism was only searching
for exact artifact without transitive dependencies.
The configuration allows resolving transitive dependencies,
but it resolves stdlib which fails because the compiler
loads plugins using parent last classloader.
Non-transitivity can be removed after parent last classloader is
removed.
Introduce a method to create org.jetbrains.kotlin.load.kotlin.MemberSignature directly from JvmMemberSignature.
Create JvmFunctionSignature from JvmMemberSignature.
We cannot create kapt configurations in `KotlinGradleSubplugin.apply`,
because `apply` is invoked after a script is evaluated, so user cannot
refer to kapt configurations in script.
We cannot call `apply` before script's evaluation, because
then we might not be able to determine
if a Gradle plugin corresponding to a subplugin is appled.
For example in case of the following script:
```
apply plugin: "kotlin"
apply plugin: "kotlin-kapt"
```
subplugin's apply will exit early because Gradle plugin "kotlin-kapt"
is not applied yet, when "kotlin"'s apply is evaluated.
since it causes numerous classloading issues. Using the wrapping types
and reload them in the proper context when needed.
Note: this version supports only classes, but the wrapping type could
be extended to support other types in the future.
+ numerous fixes related to proper loading and handling of the templates.
Alexander Udalov