#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
This problem is only relevant when isTypeRefinementEnabled == true (HMPP projects)
Ambiguity accidentally was removed after 471134d
There, for areCallableDescriptorsEquivalent we stopped assuming
as impossible a situation of having identity-different descriptors
in the same containing declaraton that still might be considered equal
So, 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 some of the usages expect that it also makes sure that descriptors
have the same substitution (see org.jetbrains.kotlin.resolve.calls.smartcasts.IdentifierInfo.Variable#equals)
So, the straight solution is using original descriptors for the cases
where we need to make sure that descriptors relates to actually different
declarations
^KT-34027 Fixed
Now, call 'configureDefaultCheckers' and 'configureExtensionsAndCheckers'
from all childs configurators, instead of taking just container from
CommonPlatformAnalyzerServices
This is needed because some IDE services tend to re-create containers
(in particular, PerFileAnalysisCache and ResolveElementCache do that to
re-inject new trace) and use usual injection DSL, which, in particular,
takes 'platformSpecificContainer'.
Returning 'common'-conatiner leads to losing all platform-specific checkers.
On the other hand, calling exactly 'configureDefaultCheckers' +
'configureExtensionsAndCheckers' should be correct, because that's how
single-platform 'platformSpecificContainer' is composed (see
PlatformConfiguratorBase), and in 'createContainerForCompositePlatform'
we don't use 'platformSpecificContainer' anyways
^KT-23305 Fixed
Note that Native built-ins are not resolved correctly in this module
(CPointed and similar). This is not a bug, but rather a technical
limitation of the current testing infrastructure: we can't depend on
kotlin-native stdlib in "big-Kotlin" repo, and native stdlib is used as
the only one source of Native built-ins.
Dmitry Savvinov