Review: https://jetbrains.team/p/kt/reviews/13334/timeline
Thanks to the previous commit, it's now possible to run
DefaultArgumentsInExpectActualizedByFakeOverride on both: frontend (FIR)
and backend (IR).
We aim to perform a thorough examination of checks involving
fake-overrides on both FIR and IR, given their distinct implementations
for handling fake-overrides.
The commit decreases scope of influence of hacky
`shouldCheckDefaultParams` flag.
^KT-63860 Fixed
Review: https://jetbrains.team/p/kt/reviews/13334/timeline
The previous code was nonsense (I wrote it). It doesn't make sense to
subtract actualOverriddenDeclarations from expectOverriddenDeclarations.
Default parameters are mentioned on the expect side. So default params
in expect/actual supertypes won't be subtracted from
expectOverriddenDeclarations (but should be)
This commit covers enum entry vs companion member case,
when two companion objects are in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets two candidates with companions.
After that it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier, so no influence here.
With two ambiguous candidates with companions for Some,
OVERLOAD_RESOLUTION_AMBIGUITY is reported.
This commit covers enum entry vs companion member case,
when one companion object is in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets the only candidate with companion.
After that it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier, so no influence here.
Finally during foo resolve it should choose between enum entry and
companion member, and enum entry wins due to KT-37591.
This commit covers object vs static member case,
when no companion objects are in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets two erroneous candidates
without companions. After it tries to resolve Some as a qualifier,
but we have no scope with a single qualifier.
That's why we finally report NONE_APPLICABLE on candidates with companions.
This commit covers object vs companion member vs static member case
but now we have two different companions (first is empty) in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets some/Some & some2/Some
because both of them have a companion. This means ambiguity.
After it tries to resolve Some as a qualifier, but we have no scope
with a single qualifier, so finally we prefer to report ambiguity
from variable access resolve.
This commit covers object vs companion member vs static member case
in situation with only one companion in the scope.
K1 reports UNRESOLVED_REFERENCE here, probably due to ambiguity.
About K2, while resolving Some.foo it first tries to resolve Some
as a "general" variable access, and gets only some2/Some
because it has a companion. Then it tries to resolve Some as a qualifier,
but here we have an ambiguity, so finally Some with companion is preferred.
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver.
See also cases (3) and (7).
In this test, things work in the similar way as in constructors case (2).
K1 resolves the explicit receiver HashMap<String, String>()
to kotlin.collections.HashMap /* = java.util.HashMap */.
K2 does the similar, but fun processConstructors from ConstructorProcessing.kt
makes a type alias substitution, so in fact constructor of expanded
java.util.HashMap is processed.
Pay attention that both frontends ignore some.HashMap and java.util.HashMap
due to ambiguous classifiers in explicit star importing scope.
See FirScope.processConstructorsByName in ConstructorProcessing.kt
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver
Again, both frontends here ignored classifiers from
explicit star imported scope (some.HashMap, java.util.HashMap)
because of their ambiguity. In case of K2, it works so due to logic
in BodyResolveComponents.resolveRootPartOfQualifier.
This function is called to resolve qualifier without receiver, in case
it's used as a receiver itself (::class counts as a selector equivalent).
In both these situations, we have some.HashMap & java.util.HashMap
from explicit star importing scope, and kotlin.collections.HashMap
from implicit star importing scope after it.
K1 ignores both explicitly imported classifiers due to their ambiguity,
and then resolves to kotlin.collections.HashMap at the next level.
In contrast, K2 takes explicitly imported classifiers and
properly reports ambiguity.
Mikhail Glukhikh