The `*Api`, `*Implementation`, `*CompileOnly`, and `*RuntimeOnly`
configurations of a `KotlinSourceSet` must not be resolved directly, as
they lack attributes needed to choose a Kotlin MPP variant, and they
must not be candidates in variant-aware resolution of a project
dependency either.
With Gradle 5.3, these configurations failed to resolve anyway, as they
had no proper `org.gradle.usage` attribute, and the disambiguation
rules of the 'java-base' plugin conflicted with the Kotlin rules.
In Gradle 5.3, there was a change to the internal logic of publishing
`SoftwareComponent`s with the 'maven-publish' plugin, and,
simultaneously, a new public API was introduced for user-defined
software components, see https://github.com/gradle/gradle/pull/8399
Earlier, the 'maven-publish' plugin used the Gradle `Usage` attribute
values to arrange the dependencies of a software component's
`UsageContext`s into the Maven scopes. Now that mechanism doesn't work
and a `SoftwareComponent` must provide an explicit mapping of the
variants to POMs by using the `SoftwareComponentFactory.adhoc` API.
However, the new API lacks some features we need to properly publish an
MPP, such as adding a component to another one as a variant, so we still
create old-style software components under the hood and
then wrap them into the new API (and then wrap the adhoc components once
again).
We also continue to use the old-style components for Kotlin-specific
logic like finding a target in another project that a dependency
resolved to, as the components produced by the new API lack crucial
information that is used in the logic, like references to
`KotlinCompilation`s.
Issue #KT-30379 Fixed
The support on our side involves:
* using the new value for Maven publishing, as the 'maven-publish'
plugin now expects 'java-api-jars' for dependency scopes ordering where
it used to expect 'java-api'
* accepting the new value in KotlinUsages compatibility and
disambiguation rules
Only Ctrl + Click is affected as find usages from Alt + F7 is a different
action (`GotoDeclarationAction` is `DumbAware`, but `ShowUsagesAction` is not).
Specifically, defer the removal of hand-written "if (true|false)" from
JvmBuiltinOptimizationLowering into codegen so that appropriate debug
info (and a NOP) can be inserted.
Change-Id: Ia11af05ad8b4251946bd3e685fb7c3319f0f433f
This however makes testLocalFunctionName fail because currently
isSubclassOf (incorrectly) returns false and therefore an anonymous
class is generated and the name is taken from there. The name there is
"box$OK" which is incorrect. The isSubclassOf issue is KT-28198 and will
be fixed separately; the incorrect name issue will be investigated later
In Android projects we need to detect modules by inspecting jar files
in order to find build history files.
However `useModuleDetection` property was not set up correctly for
KaptGenerateStubsTask.
#KT-29761 Fixed
Apply a compromise strategy between "no report" and "always report".
Report only for several days after release and don't bother users afterwards.
#KT-30388 Fixed
All exceptions still can be found in Idea Log.
Toshiaki Kameyama