- `ImportedFromObjectCallableDescriptor` and descriptors in general do
not have consistent `equals`, which leads to duplication in completion
when multiple functions from objects are imported, or when function is
visible in some scope both implicitly and by import (see KT33903_1.kt)
- ^KT-33903 Fixed
Given that the Kapt subplugin creates new tasks, it is impossible
to run it in the context of lazy task configuration. Disable lazy
task configuration for Kotlin/JVM by always accessing the task
instance until subplugins are refactored to be able to properly
work with task configuration avoidance.
Replace the old ad-hoc task matching mechanism used for connecting the
compilation tasks that need to share internal visibility with an
implementation based on the associate compilations and compilation
outputs rather than `destinationDir`s of the tasks.
The only place that still requires ad-hoc friend paths is the Android
instrumented tests compiling against the JAR of the main variant, not
its classes dirs. Support that with `friendArtifacts`.
Issue #KT-17630 Fixed
Issue #KT-20760 Fixed
As associated compilations will see internals of each other, they now
need to share the module name for the compiler to be able to correctly
generate calls to the internals.
Move `moduleName` to `KotlinCompilation`.
Group associate compilations into modules in a DSU-like way, use a
single module name for all of the compilations grouped into a module.
Add non-public API for the IDE to query additional visible source sets
for each source set.
Implement visibility inference via associate compilation links.
Implement visibility requirements for source sets and requirements
satisfaction checks in Gradle build.
Partial implementation of the associate compilations proposal. A
compilation can now contain links to other compilation that it compiles
against. This links will replace ad-hoc inter-compilation dependencies.
Issue #KT-34009 Fixed
The `KotlinAndroidPlugin` used to support two different sets of APIs of
the Android Gradle plugin and used `AbstractAndroidProjectHandler` to
wrap those APIs. Now that there's only one implementation, it
doesn't need the generic `V` (variant data), and some cleanup is needed.
The compilation outputs of Android compilations accidentally were left
empty. The `destinationDir`s of the Kotlin & Java tasks should be
registered in the `output.classesDirs`.
This function used to only calculate the mapping once and store it for
the project, so it was unsafe to use early. Fix that by evaluating the
value each time and then freezing it at the point of either task graph
being ready, or any task being executed.
Also, store the map in the project's `ext` rather than in a static weak
hash map, which is safer wrt memory leaks.
Dmitriy Dolovov