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)
Mads Ager