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)
Ivan Gavrilovic