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
This is needed for some IDE clients, particularly, completion: even
though presenting only non-converted member (e.g., 'foo(Consumer<Int>')
is nominally OK, as resolution with NI is smart enough to accept 'foo { }'
for such a call, it is inconvenient for users (for example, hitting
enter would insert round brackets instead of a figure brackets)
This commit adds very-very narrow API (borderline hacky) in
JavaSyntheticScopes, to allow clients explicitly ask for a scopes with
force-enabled synthetic conversions. It fixes several tests, which had
started to fail after corresponding commit about NI and SAM-adapters
(fe5976d7f4), e.g.:
- Java8BasicCompletionTestGenerated.testCollectionMethods
- Java8BasicCompletionTestGenerated.testStreamMethods
- JvmBasicCompletionTestGenerated$Common$StaticMembers.testJavaStaticMethods
- JvmBasicCompletionTestGenerated$Java.testSAMAdaptersStatic
- JvmWithLibBasicCompletionTestGenerated.testSamAdapter
- JvmWithLibBasicCompletionTestGenerated.testSamAdapterAndGenerics
Note that changes are made in ReferenceVariantsHelper, which is used by
several other clients in IDE. Presumably, those changes are needed for
them too.
This is a large commit, which introduces general API for working with
abstraction of Platform.
- Add new abstraction to 'core' - SimplePlatform - which represents
exactly one platform
- Clients are strongly prohibited to create instances of SimplePlatform
by hand, instead, corresponding *Platforms abstraction should be used
(e.g. JvmPlatforms, JsPlatforms, KonanPlatforms)
- Move TargetPlatform to 'core', it represents now a collection of
SimplePlatforms
- Clients are strongly encouraged to use TargetPlatform
(not SimplePlatform) in API, to enforce checks for multiplatform
- Provide a helper-extensions to work with TargetPlatform
(in particular, for getting a specific component platform)
- Remove MultiTargetPlatform in favour of TargetPlatform
- Notably, this commit leaves another widely used duplicated abstraction,
namely, IdePlatform. For the sake sanity, removal of IdePlatform is
extracted in the separate commit.
To ensure stable results of subsequent resolution api method calls,
it is require to provide same resolution facade, as
getResolutionFacade function doesn't guarantee to have same result in
subsequent calls due to soft caching
Other facades (JVM, Common, Native) are already created with such flag.
This should stop some known 'rewrite at slice'-exceptions from being
thrown (KT-21405, KT-29705).
For a more thorough investivation and details, refer to KT-30031.
Also, see KT-30030: even though it was fixed by the different commit,
the same scenario probably can be used to investigate other rewrites
(even though they will reproduce much less frequently than original
issue)
^KT-21405 Fixed
^KT-29705 Fixed
There is no Java support in CIDR. Therefore:
- analyze KTS in CIDR using Common platform
- disable error highlighting for KTS in CIDR
Issue #KT-29953 Fixed
Dmitry Gridin