To be more precises, ResultTypeResolver for K2 now searches for
similar LOWER/UPPER constraints pair based on the same flexible type,
like LOWER(CapturedType&Any..CapturedType?) and UPPER(CapturedType!).
If such a pair is found, the CapturedType is not approximated.
This is done to avoid a big difference between this case and
completely same constraints, like LOWER(CapturedType!) and
UPPER(CapturedType!). In this case we squash them to EQUAL(CapturedType!)
even before ResultTypeResolver, and captured types which is got from
an EQUAL constraint are not approximated even before this commit.
This commit fixes back a case from KT-50134 and a problem with intellij.vcs.git
#KT-65596 Fixed
This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
PCLA-related changes led to this change in
behavior. In K1 an explicit cast was needed
to prevent ORA, but now in K2 this code
is green without casts.
^KT-50293 Obsolete
This makes it more consistent and fixes some
overlooked corner cases. Also it was decided
on the last equality applicability DM
(KT-62646) that we'd like
`is`/`!is`/`as`/`as?` to work similarly
to `===`/`!==`.
Also note that it now gives a clearer
explaination of why some corner cases work
the way they do. For example,
`FirPsiDiagnosticTestGenerated.testLambdaInLhsOfTypeOperatorCall`
yields `UNCHECKED_CAST` instead of
`CAST_NEVER_SUCCEEDS`, because
`toTypeInfo()` replaces all type arguments
with star projections, even when the argument
is not a type parameter. This is because
it has been desided to work this way in
KT-57779.
In
`FirPsiOldFrontendDiagnosticsTestGenerated..NeverSucceeds#testNoGenericsRelated`
the diagnostic is introduced, because
`t2 as FC1` and `FC1` is a final class with
no `T5` supertype.
`UNCHECKED_CAST` in
`FirPsiOldFrontendDiagnosticsTestGenerated.testSmartCast`
disappeared, because previously we didn't
take smartcasts into account.
Note that
`FirPsiOldFrontendDiagnosticsTestGenerated.testMappedSubtypes`
is a false positive. It appears because `isSubtypeOf()` doesn't
take into account platform types in supertypes of the given types
(doesn't map them).
FirCallResolver tries to find a
candidate for the delegate's getValue and cannot parse an arrayLiteral
with a nullable coneType.Running
FirCallCompletionResultsWriterTransformer.transformArrayLiteral is
required to find the result type. Therefore, completeCall should not be
invoked with the ResolutionMode from the 'data' param, but rather in
ResolutionMode.ContextIndependent.
#KT-65022 Fixed
Previously, it was failing at line
(resolvedReceiver?.toReference(session) as? FirNamedReferenceWithCandidate)?.candidate?.updateSourcesOfReceivers()
But this line was mostly incorrect because in case of `a.b()` call,
which is resolved to `a.b.invoke()`, `resolvedReceiver` is pointing to
`a` instead of obviously expected `a.b`.
The fix with using `candidate.callInfo.explicitReceiver` doesn't help
either because the candidate of that receiver is always completed at
that stage (so no Candidate there).
The only case when the candidate was still there is PCLA because
in that case we explicitly don't fully complete even receiver
expressions.
(see docs/fir/pcla.md)
The idea of the fix is moving the call of `updateSourcesOfReceivers`
for invoke property receiver to the place just before the candidate
is being converted to the resolved reference
(i.e., the candidate is being lost)
^KT-66148 Fixed
This is necessary for inference to work like in K1 because we only
add equality constraints from expected types on top-level `when`, not
on nested ones.
#KT-65882
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
Checker for conflicting declarations will now check for the following
scenarios too
- two expect declarations in different modules
- actual and non-expect declarations in different modules
^KT-63826 Fixed
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
... when the expected type is not a function type.
Instead set it to a new type variable.
This fixes a bunch of false negative CANNOT_INFER_PARAMETER_TYPE.
#KT-59882 Fixed
Generally the wrapping anonymous initializer can be used as a
"containing declaration" for some elements, but since the initialiser
for the last script expression could be dropped (the expression could
be converted to the result property), this may lead to the surprises,
e.g. as described in KT-65984
This fix marks the last initialiser as local, preventing it from being
referenced as "containing declaration".
#KT-65984
Before this commit, the expect-actual resolver could find expects in
regular dependencies
Note: The appeared `VIRTUAL_MEMBER_HIDDEN` in
compiler/fir/analysis-tests/testData/resolveWithStdlib/multiModule/FakeOverrides.kt
isn't caused by my change. It's caused by fixing the testData dependency
syntax notation.
The testData improperly used regular dependency syntax notation, while
it should have been using dependsOn
Before:
Regular dependency syntax notation
// MODULE: androidMain(commonMain)
After:
dependsOn dependency syntax notation
// MODULE: androidMain()()(commonMain)
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`.
Mikhail Glukhikh