- Use 'null' as indicator of non-MPP version. Consequently, remove
useless 'isMpp' method, and lift all methods to extensions (to be able
to call them on nullable 'facetSettings.mppVersion')
- Change semantics of extensions to check for exact equality rather than
for "at least specified version"
- Deprecate old MPP-versioning in favour of 'facetSettings.mppVersion'
- it is required to be able to autoimport extensions from objects,
not only from the top level
- use `substituteExtensionIfCallable` to handle generics for extension methods
- move finding expression receivers to the separate method, add `Receivers` value class to hold found receivers
- change `CallableDescriptor.isValidByReceiversFor` to return false
if explicit receiver is not required for the descriptor
- ^KT-34000 Fixed
script templates that are loaded from compiler settings are subscribed on this topic.
When ScriptTemplatesFromCompilerSettingsProvider invokes KotlinCompilerSettings.getInstance, deadlock may happen if those settings aren't initialized yet.
^KT-25373
testJavaGetterToOrdinaryMethod_JavaGetterToOrdinaryMethod
testSyntheticPropertyUsages1_RenameGetMethod
from 192 disabled to call findReferences(elem), so overload does not worked
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
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
For compiled scripts there is AbstractIdeCompiledLightClassTest
For now there is a difference in light classes constructed from source and from compiled class (missing baseClass and constructor parameter for script class)
But it doesn't affect users because calling script class from Java isn't supported yet
testData for AbstractIdeLightClassTest and AbstractIdeLightClassForScriptTest can be merged when the difference will be fixed
Dmitry Savvinov