While reporting a diagnostic there seems to be correct because the
parameter type is ConeErrorType, the former fact is a bug
in PCLA that should be fixed soon
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
This diagnostic may be reported even without any compiler plugins (e.g.
for annotation named `Target` or `Deprecated`), so the old name
and message were quite confusing
^KT-64654
This commit breaks two diagnostic tests:
- testSuspendJavaImplementationFromDifferentClass
- testSuspendJavaOverrides
Related to KT-59818
#KT-63233 Fixed
There are many complications with the current design of passing data
from within in-place lambdas to surrounding code. Solving these
complications will involve more time to investigation than is available
within the K2 release. So we are disabling passing type statement
information from lambdas for the time being until more time can be
devoted to a more complete solution.
^KT-60958 Fixed
^KT-63530 Fixed
This commit solves a stub type inconsistency problem.
As a part of KT-59369 fix we decided (see commit 299d2799),
that ConeStubTypeForChainInference has a scope of Any,
so we can safely resolve only to equals/hashCode/toString.
However, later we can replace a stub type with some inferred type,
which can have its own equals/hashCode/toString implementation,
while the call still refers Any member.
In this situation FIR2IR decides that we are calling a fake override,
which is not true, in fact we are calling an overriding method.
This leads to a crash in Native backend.
To solve this situation, we provide an explicit cast of a dispatch
receiver with a stub type (ConeStubTypeForChainInference) to Any,
thus confirming directly we are calling Any method and nothing else.
#KT-63932 Fixed
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.
In this test, both frontends resolve to fun Semaphore.
Both work this way because interface/class Semaphore classifiers are
clashed (ambiguity) and ignored.
K2 reports ambiguity for some similar cases,
but constructor resolve still ignores ambiguous classifiers when found.
(see FirScope.processConstructorsByName in ConstructorProcessing.kt)
In this test, K1 resolves 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
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This commit actually does two things:
- Adds Any scope to stub type
- Makes CheckDispatchReceiver treat stub types
as non-null for the unsafe call check to make such candidates viable
Related to KT-59369
In certain situations like constructor calls, it's possible
to have different WasExperimental/SinceKotlin pairs associated
with one use-site, e.g. a constructor call is associated both
with a constructor declaration and a class declaration.
However, looks like it make no sense to handle this situation
in FirSinceKotlinHelpers, because FirOptInUsageBaseChecker already
handles them.
#KT-59825 Fixed
Denis.Zharkov