When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Since d0ca0dca2b
first IC build uses CompilationMode.Rebuild instead of Incremental
to avoid unnecessary work (computing API difference etc.).
However there is a branch that does not transform source files
paths to absolute ones before writing them to module xml file.
In our plugins we have always transformed files to absolute ones before
passing them to IncrementalJvmCompilerRunner, so there is no problem.
But third party build systems could pass relative paths to IncrementalJvmCompilerRunner
(namely Kobalt does so).
It turned out to break builds because KotlinToJVMBytecodeCompiler takes
module xml file's (which is a temporary file itself) parent as a base
for relative source files (see KotlinToJVMBytecodeCompiler.getAbsolutePaths).
This change ensures that makeModuleFile always uses absolute files.
#KT-22542 fixed
The problem may happen in case of multi-module projects:
If a Java class was effectively unused in one module (A),
but it's used in kt-files from the dependent module (B) then
we wouldn't track the changes of the class while compiling A
and don't recompile its usages in B.
It happens because now we track only Java classes that were
resolved by out frontend instead of all classes in the module
that would be more correct but it might be rather slow.
The idea is that whenever we see change in an untracked Java file
we start tracking the classes in it and for the first time we mark
all its content as changed.
It was already working in JPS, because it see our synthetic classes
as subclasses for SAM's, but with non-JPS build we have to manually
tracking places that should be recompiled after SAM members are changed
See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
The new name is more convenient and precise because this module is no
longer only about loading declarations from Java, it also contains
implementation of loading Kotlin declarations from .class files, as well
as type mapping abstractions, JVM ABI specifications, etc.
Alexey Tsvetkov