Compiler check for 'when' exhaustiveness requires that module
descriptors of a sealed class and its inheritors are the same (reference
identity matters). Prior to this commit and under some conditions they
were not. Details follow below.
Resolution related data structures (resolution facades) are organized
into trees (sdks, libs, and modules have their own nodes/facades,
module/class descriptors are stored inside). And the trees themselves
are put into a map associating so called PlatformAnalysisSettings and
GlobalFacades (plays a role of a root). PlatformAnalysisSettings is an
abstraction describing target platform and sdk of a module. The more
combinations exist for a project the more facades are used. Please, see
KotlinCacheService for more details.
So why a module can have multiple ModuleDescriptor-s?
Every tree mentioned above is an isolated resolution environment
containing its own instances of the outer world descriptors. Say, if a
project has modules X, Y, Z and we consider X then all three might have
their own vision of X, i.e. 3 descriptors exist at a time.
What descriptor instance does compiler get?
The path starts when the user opens a file in the editor and
highlighting pass starts (see usages of
ResolutionUtils#analyzeWithAllCompilerChecks). Module descriptor stored
in the resolution tree of the file's module gets injected into the
compiler's context. Starting from this moment compiler sees other
modules through the prism of a single resolution facade (tree).
Descriptors residing outside are alien.
This commit allows IdeSealedClassInheritorsProvider to figure out what
PlatformAnalysisSettings are associated with the resolution facade (read
ModuleDescriptor) seen by the compiler. Later on the same facade is used
to provide correct instances of sealed inheritors back to the compiler.
While we trying to find an inlined SourcePosition, the body should be
resolved KotlinPositionManager.getLambdaOrFunIfInside / InlineUtil.isInlinedArgument
to make shure the lambda is an argument for a call.
#KT-39309 fixed
#KT-39435 fixed
* Change parameter type quickfix: fix it works correctly on property delegate
#KT-15846 Fixed
* Change parameter type quickfix: fix it works correctly when function literal has trailing comments
#KT-15846 Fixed
- Replace leaking ModuleResolverTracker with use of ModuleDescriptor.Capabilies
- Provide API for retrieving ResolverForProject from ResolutionFacade
- Update names
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
- change `detectReceiverTypes` return type to `List` instead of `Collection`
- it reflects that receiver types are actually ordered
- did not propagate signature changes to all possible places because it creates too much noise in git history
- ^KT-30996 Fixed
It is very slow in completion for build.gradle.kts because it creates SAM adapters for constructors of all imported classes
Note that those SamAdapters weren't shown in completion in any case because they were filtered by name filter (SamAdapters for constructors have <init> name)
Refined types with non-trivial substitution may result in different
descriptors instances
See PsiUnifierTestGenerated$Equivalence$Expressions.testArrayAccess
Andrei Klunnyi