To enable parallel tasks execution within a project,
add 'kotlin.parallel.tasks.in.project=true'
to gradle.properties or local.properties file .
#KT-28155 fixed
This commit restores the heuristic removed in 9df02b2366, but only
enables it in case the class wasn't found with the name mapped initially
according to the InnerClasses attribute values. This helps to support
class files which do not have the InnerClasses attribute for all nested
referenced classes, such as those generated by Groovy.
Note that in theory it's still possible for this code to behave
incorrectly, for example a reference to a class `C` nested in a
_top-level_ class named `A$B` will not be loaded by this code correctly.
This is a lower-priority issue and it will need to be fixed later.
#KT-27874 Fixed
The existing disambiguation rule for the Usage attribute lead to
runtime variants being resolved even for compile-scoped input
configurations, because Gradle runs disambiguation rules even if the
consumer value is present in the candidates list.
For example, an `app` project's `jvmCompileClasspath` configuration
would get its `project('lib')` dependency resolved to the
`jvmLibRuntimeElements` instead of `jvmLibApiElements`.
Fix this by:
1) running the part of the disambiguation rule only with Gradle 4.1+, so
as to use the consumer value for proper disambiguation;
2) choosing the JAVA_API usage when the consumer is JAVA_API or
KOTLIN_API, and choosing one of the JAVA_RUNTIME usages if the
consumer is either KOTLIN_RUNTIME, one of the JAVA_RUNTIME usages, or
does not specify its usage.
Issue #KT-27849 Fixed
Declaring Groovy and Kotlin classes in the same project is not necessary
for this test, split them to two projects instead to avoid the hack with
modifying task dependencies manually
Preface: for Groovy traits with fields, the Groovy compiler generates
synthetic "$Trait$FieldHelper" classes which posed several problems to
our class file reader, caused by the fact that the contents of the
InnerClasses attribute broke some assumptions about how names on the JVM
are formed and used.
For a trait named `A`, the Groovy compiler will additionally generate a
synthetic class file `A$Trait$FieldHelper` with the following in the
InnerClasses attribute:
InnerClasses:
public static #15= #2 of #14; //FieldHelper=class A$Trait$FieldHelper of class A
i.e. the simple name of the class is `FieldHelper`, the name of its
outer class is `A`, but the full internal name is `A$Trait$FieldHelper`,
which is surprising considering that the names are usually obtained by
separating the outer and inner names via the dollar sign.
Another detail is that in some usages of this synthetic class, the
InnerClasses attribute was missing at all. For example, if an empty
class `B` extends `A`, then there's no InnerClasses attribute in `B`'s
class file, which is surprising because we might decode the same name
differently depending on the class file we encounter it in.
In this change, we attempt to treat these synthetic classes as top-level
by refusing to read "invalid" InnerClasses attribute values (they are
not technically invalid because they still conform to JVMS), fixing the
problem of "unresolved supertypes" error which occurred when these
classes were used as supertypes in a class file in a dependency.
1) In ClassifierResolutionContext.mapInternalNameToClassId, do not use
the ad-hoc logic (copy-pasted from intellij-core) to determine class
id heuristically from the internal name. For $Trait$FieldHelper
classes this logic attempted to replace all dollar signs with dots,
which was semantically incorrect: dollars there were used as
synthetic characters, not as a separator between outer and inner
classes.
2) In isNotTopLevelClass (Other.kt), only consider "valid" InnerClasses
attribute values, where the full name of the class is obtained by
separating the outer name and the inner name with a dollar character.
This way, we'll be able to treat class files with invalid attribute
values as top-level and avoid breaking any other assumptions in the
class file loader.
3) In BinaryJavaClass.visitInnerClass, record all valid InnerClasses
attribute values present in the class file, not just those related to
the class in question itself. This is needed now because previously,
the removed heuristics (see p.1) transformed mentioned inner class
names to class ids correctly >99% of the time. Now that the
heuristics are gone, we'll use the information present in the class
file to map names correctly and predictably. According to JVMS, this
attribute should contain information about all inner classes
mentioned in the class file, and this is true at least for class
files produced by javac.
#KT-18592 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.
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
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
The traditional Gradle/Java model assumes several configurations, which
are now deprecated, which are both `canBeConsumed = true` and
`canBeResolved = true`.
* compile, testCompile, etc.
* runtime, testRuntime, etc.
* default
These configurations need to somehow resolve correctly to an appropriate
platform-specific artifact when they contain an MPP library or project
dependency.
However, simply marking them with the Kotlin platform type attribute
would put these configurations under considerations during Gradle
variant aware depdendency resolution of project dependencies, which
in order would lead to ambiguity (e.g. `compile` vs `runtime` vs
`testCompile` vs ... vs `apiElements`).
To deprioritize these configurations during dependency resolution, we
mark them with a special attribute with a unique value in each project.
Given that the values are different in different projects, Gradle will
not choose a configuration marked by this attribute.
But we still need 'project(path: '...', configuration: '...')`
dependencies to work, and so, instead of rejecting those different
values of the attribute, we say that all values are compatible, but
when an ambiguity arises, choose the configurations not marked by this
attribute, so effectively eliminating them from resolution.
Issue #KT-27111 Fixed
* Add resources processing to the K/N compilations
* Use a proper resources output path (composed from target + compilation
rather than just compilation name)
* Fix incorrect reassignment of the resources directory
When a new MPP is published without Gradle metadata, the project
dependencies should be replaced with specific module dependencies,
e.g. `sample-lib` with `sample-lib-jvm`, because a consumer won't be
able to resolve `sample-lib` in a variant-aware way.
The following parts of the publications are affected:
* root publication
* with Gradle metadata, it is published and references the
other publications using the `available-at` mechanism
* without metadata opt-in, it is not published
* Kotlin metadata variant
* with Gradle metadata, it is added as an additional variant to the
platform-specific publications to allow the IDE to discover it
* without metadata opt-in, it is added as a dependency to the platform-
specific modules (like in old MPP)
When a non-Kotlin (JVM) project resolves an MPP library dependency,
it expects only one variant per Java Usage value ('java-api',
'java-runtime-jars'). If there's more than one, it will report
ambiguity and fail.
So we need to avoid creating non-JVM variants with Java Usage values
to ensure that non-Kotlin consumers can resolve the dependencies on
an MPP library with a single JVM target (if there's more than one
JVM target, there will still be ambiguity, but that's quite what one
would expect and what can be solved with custom attributes).
Instead, we define two Kotlin-specific Usage values, 'kotlin-api' and
'kotlin-runtime', so that:
* input configurations with these Usage values can consume plain Java
artifacts, for compatibility with plain old Kotlin modules
* if a consumer does not request a Kotlin usage and receives the two,
let it use the runtime one as it is more complete
We then use the two Usage values on those Kotlin input and output
configurations which are not JVM-related, and leave the Java Usages
for the JVM targets.
Instead of simply adding all Kotlin source sets participating in an
Android compilation, as was appropriate until we introduced the
dependsOn relation, we should now build a proper source sets hierarchy.
By default `validateTaskProperties` is added only to `check` task's
dependencies, so doesn't run on our CI.
We can run `check` instead of `test` on CI, but since developers are
not used to it, I believe it's better to make `test` tasks depend on
`validateTaskProperties`
Also, fix empty configurations created for targets that have no runtime
outputs (metadata ones, especially), which could get chosen by Gradle
during dependency variant-aware resolution of a `project(...)`
dependency.
See also: d13ca38
With the attribute set, an input configuration that does not require the
Gradle's USAGE attribute but requires Kotlin platform metadata, will
fail to resolve because the attributes set on the consumable
output configurations are not subsets of each other, as follows:
> Cannot choose between the following variants of project :lib:
- metadataApiElements
- metadataDefault
- metadataRuntimeElements
All of them match the consumer attributes:
- Variant 'metadataApiElements':
- Found org.gradle.usage 'java-api' but wasn't required.
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
- Variant 'metadataDefault':
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
- Variant 'metadataRuntimeElements':
- Found org.gradle.usage 'java-runtime-jars' but wasn't required.
- Required org.jetbrains.kotlin.platform.type 'common' and found
compatible value 'common'.
Issue #KT-26383 Fixed
Alexey Tsvetkov