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
Return the destination array instead of the destination storage array
wrapped in a new unsigned array. The difference should be
indistinguishable, however in JS, where inline classes are not inlined yet,
it had resulted in an extra wrapper.
Sergey Igushkin