to avoid unnecessarily loading unchanged ones.
Duplicate classes will make this a bit tricky. This commit outlines the
algorithm to handle them, the full implementation will follow later.
Also handle removed classes when computing classpath changes.
Test: New tests in ClasspathChangesComputerTest
When in 'lenient' or 'classpath' mode, Gradle will catch exceptions
during project evaluation and collect them into the
'ClassPathModeExceptionCollector'.
Running checks on the project after evaluation should only happen
if the project is properly configured (aka no such exceptions collected)
to prevent false positive error reports (that will then fail
the Gradle process and swallow the real cause)
^KT-48823 Verification Pending
Workers usually execute later than task action and does not raise
exception to the task. Such behaviour skips task outputs restoration to
the pre-execution state.
Kotlin compiler on incremental compilation error leaves 'dirty*' files
in the build output, forcing Gradle to run non-incrementally on the
next build. Fixed it by moving task outputs reset logic into worker as
well.
^KT-46406 In Progress
When toolchain is not configured, Kotlin sets by default JVM target to
"1.8". Compiling Kotlin project on JDK 9+ produces JVM target mismatch
warning even if Java sources are empty.
Skip the jvm validation check if associated Java task sources are empty.
^KT-48745 Fixed
This setup requires a 'jvm like' target and an orphan source set, which
depends on 'commonTest'. This orphan will not participate in any
compilation and therefore will not have any platform.
The code expected at least one test task for this source set
and therefore at least one test framework.
^KT-46273 Verification Pending
There are certain classes that we are not yet able to take snapshots of,
either because the class is faulty, or there is a bug in our code.
For these classes, we will use a special snapshot and fall back to the
existing approach to compute classpath changes.
In the short run, we will update this list of cases as they arise. In
the long run, we will:
- Fix all cases that are caused by bugs in our code.
- Decide what to with the faulty jars in general and remove the list.
Test: The following should pass
- Step 1: ./gradlew publish
- Step 2: ./gradlew publish -Pbootstrap.local=true
-Pbootstrap.local.path=/path/to/kotlin/build/repo
-Pkotlin.incremental.useClasspathSnapshot=true
Previously the validation was inconsistent allowing non-incremental builds without Kotlin sources to pass successfully with JVM target misconfiguraiton but fail incremental builds
#KT-48408 Fixed
Shared Native Compilations seem to already implicitly add a
dependency on the stdlib. Adding it again will result in a
'library included more than once' warning.
^KT-46257 Verification Pending
Previously it was only populated when KGP was applied to the root project.
CLI compilation would still work, since it also checks for the
new hmpp properties, whereas the IDE import is still 'just' checking
on the old property (while defining its own defaults)
^KT-48513 Verification Pending
Compiler runner used incorrect cache key for isolated classloader:
it didn't take the actually used compiler jar into account,
only the K/N home dir.
Fix this by using the entire classpath as a key.
When running tool in-process, log the actual classpath extracted from
the classloader, not the one that was intended.
This helps to detect the cases when these two don't match.
Yahor Berdnikau