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.
* KotlinExecution
* KotlinExecutionSource
* KotlinTestRun
* Aggregating executions and execution sources
* KotlinTargetWithTests
* Add a `testableTargets` extension
* Make some Kotlin/Native targets testable (this requires
having a separate preset type for them)
* Implement test runs encapsulating the tests for all
existing testable targets by refactoring their
TargetConfigurator classes
Issue #KT-32679 Fixed
Alternative message for errors, caused by unexpected lambda expression arguments on a new line.
Both diagnostic are reported, if multiple lambda expressions were passed to the call.
For other errors trailing lambda diagnostic overrides the original one.
Quickfix for erroneous trailing lambdas on a new line after call.
Fix separates lambda expression from previous call with semicolon.
All trailing lambda arguments become standalone lambda expressions.
Add test for aggregating incremental annotation processors and JDK9.
This makes sure the implementation is not using any types that have
been removed in JDK 9.
This class does not exist in JDK9, so running incremental KAPT on
JDK9 fails. Because it is used only to get the name of the file,
this has been replaced with usage of the public JavaFileObject API.
Avoid using JavacProcessingEnvironment.validImportStringToPattern method
because it has been removed in JDK9. This commit changes how we compute
pattern to match the class names, and it create instances of Pattern
manually by following spec for Processor.getSupportedAnnotationTypes().
Support for module prefix is not added yet.
This testdata was written when there was no "operator" modifier.
After a83225218f rules for operators become stricter and now functions without operators are not considered as such
If the scope for a local variable is started before a value
has been written, another value from a previous use of the local
slot can be present. That value could have a different type which
would lead to weird debugging situations and also leads to other
tools (such as D8) rejecting the locals information as it is
invalid.
Fixes KT-33959.
As fqNames of some symbols may change during conversion
E.g, when moving Java static method to Kotlin companion object
#KT-19607 fixed
#KT-32903 fixed
#KT-33743 fixed
#KT-33556 fixed
Previously, BuiltInsCache was a separate abstraction with its own
lifecycle. In particular, it had a CachedValue inside, which uses
SoftReference to hold the computed data. This is bad, because this might
lead to disalignment of lifetimes with respective ResolverForProject,
leading to potential exceptions in analysis, see KT-33504 for details.
This commit fixes it by making root ResolverForProject own BuiltInsCache
and removing any logic about invalidation from BuiltInsCache. So, now,
BuiltInsCache is disposed iff corresponding ResolverForProject is
disposed
^KT-33504 Fixed
Previously, ResolverForProjectImpl had multiple callbacks in
constructor. Some of those callbacks were used only to overcome module
visibility and provide an ability to inject IDE-specific logic into
compiler (ResolverForProject is in the 'compiler'-module)
This commit introduces abstract class which implements
environment-independent logic (previously, this logic had been stored in
ResolverForProjectImpl) with several abstract met hods (previously,
callbacks). Then, we provide few concrete implementations of
AbstractResolverForProject with clear semantics:
- IdeaResolverForProject: resolver used in IDE, where we have indices,
oracles, multiple modules, etc.
- ResolverForSingleModuleProject: resolver for project with only one
module, commonly used for CLI compiler/tests
- one anonymous implementation for MultimoduleTests
This refactoring achieves several things:
- now it is easier to see what kinds of ResolverForProject you might see
in some particular environment (previously, one had to inspect all
call-sites of constructor)
- we can easily add IDE-specific logic in IdeaResolverForProject without
adding noisy callbacks (which most probably wouldn't have any other
non-trivial implementations)
Sergey Igushkin