When a non-MPP is imported into the IDE, the importer anyway tries to
build the MPP source sets model, so it tries to access the
`compilerPluginArguments` and `compilerPluginClasspath`, resulting in
an import error.
Issue #KT-27646 Fixed
If a source set is used in only one compilation, take the options from
its compile task.
If a source set is used by multiple compilations of a single target,
either choose the 'main' compilation or choose any (this will happen
for Android, and it looks OK for the first time). If there are multiple
compilations of different targets, use the metadata compilation.
Issue #KT-27499 In Progress
Add the corresponding Gradle plugin DSL, consistency checks, and logic
for propagating these settings to the compiler during build.
Issue #KT-26840 In Progress
BuildOutputCleanupRegistry tracks the all of the outputs that belong to
the Gradle build, so when Gradle runs in an unknown state (e.g. without
any history), it can detect stale outputs in the output directories and
delete them.
Since this is an internal API, its usage is removed. Instead, another
way to tell Gradle that a set of directories belongs to the build is to
add them to the `delete` task targets.
Remove the implementation of the `FileCollectionInternal` interface in
`KotlinCompilationOutput`. This interface may change unexpectedly (and
does between Gradle 4.10 and 5.0) so we need to get rid of its
implementation.
On the other hand, we can't just implement `FileCollection` instead
because Gradle internally assumes that all `FileCollection` instances
are also `FileCollectionInternal`. So the way to fix this is to remove
`SourceSetOutput` from superinterfaces of `KotlinCompilationOutput`
altogether.
Instead, to work with `SourceSetOutput` and `KotlinCompilationOutput`
in a uniform way, provide a wrapper for `SourceSetOutput`:
`KotlinWithJavaCompilationOutput` that is basically a proxy
class.
Shared instance is incorrect here and causes clashes when many
definitions are loaded in the same process.
Also make the diagnostics in case of clashes more verbose.
When Gradle resolves a dependency on a publication with no metadata
(or with metadata disabled), it represents it as two variants, one with
Usage `java-api`, the other with `java-runtime`. It turns out that the
`java-api` one does not contain transitive dependencies with Maven scope
`runtime`.
This commit makes the Kotlin Gradle plugin disambiguation rules behave
the same way as those defined in the JavaBasePlugin: when no Usage is
requested, prefer the runtime usages as they are more complete.
* Fix bugs causing early task evaluation
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
* Fix merge mistakes
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
* Fix another call forcing tasks evaluation Add a test for lazy tasks
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
A KNPE happened because Gradle 4.7 (but not 4.8+) requested a
publication's dependencies before all other publications were created.
Issue #KT-27231 Fixed
Anton Bannykh