Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
As the result of the latest changes to stdlib, the muted test succeeds.
Thus "java.lang.AssertionError: Test contains MUTE_LL_FIR directive but
no errors was reported. Please remove directive".
It was decided to unmute the test for now until the compiler team
fixes the issue. See KT-65218
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
In more details, we use either platform override checker (if we came
from platform) or the combined intersection scope override checker
at this place. Also this commit fixes various places around
JavaOverrideChecker, allowing to apply it in intersection override
checker properly:
- don't consider return types in this place
- apply JavaOverrideChecker if at least one candidate is from Java
- compare type primitivity closer to K1 logic
#KT-62554 Fixed
Partially fixes KT-63242
The inter-module interaction was partially supported, but the
DiagnosticCompilerTestFE10TestdataTestGenerated and
LFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated were
failing. This is because the arguments of annotations were not fully
resolved in loadExperimentalitiesFromAnnotationTo function.
^KT-60262 Fixed
At the moment, SubclassOptInRequired is marked with the
ExperimentalSubclassOptIn annotation. However, it does not work
as expected due to a missing opt-in error. To use SubclassOptInRequired,
an explicit opt-in is necessary because SubclassOptInRequired is an
unstable feature now.
^KT-64739
Previously, if the parent class was in Java code and the subclass in
Kotlin, the opt-in usage error would not be reported for the subclass.
The problem was that the extractClassFromArgument function couldn't get
the class type from Java code. It was looking for a ConeClassLikeType,
but found a ConeFlexibleType instead.
#KT-60258 Fixed
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).
Nikolay Lunyak