^KT-64187 Fixed
Review: https://jetbrains.team/p/kt/reviews/14807
I also checked that IDE sets metadataCompilation to `true` (Actually, it
looks like IDE performs analysis two times with the flag having
different values, but whatever, maybe it's even better this way)
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
`T.() -> R` and `(T) -> R` should only be
different for resolution, but casts are only
about typechecking. Values of either of
these types can always be put into variables
of the other type.
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).
They are not `FirRegularClassSymbol`, but are
final. `FirClassSymbol` is enough, because
`toSymbol()` returns `FirClassifierSymbol`, and:
- type parameters are always expected to have
subtypes
- typealiases have been expanded in the
previous line
It was decided to forbid such comparisons,
as we know how `===` works. Also, added some more
test cases, just for comparison.
Reusing the proper `canHaveSubtypes()`
from `TypeUtils` prevents a breaking change
in:
- `comparingTripleWithPair.kt`
- `comparisonOfGenericInterfaceWithGenericClass.kt`
But it does lead to warnings
(instead of errors) in
`incompatibleEnumEntryClasses.kt`, which is an
unrelated mistake that will be fixed in the next
commit.
The refactoring in `canHaveSubtypes()` is purely
cosmetic - otherwise reading these conditions is hard
(and they don't fit my screen vertically).
^KT-62646
^KT-65541
^KT-57779
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
Return type computation of getter for synthetic property, which is
incompatible anyway (e.g. because there is no java in the hierarchy)
may cause excess dependency between return types of declarations, which
may lead to recursive problems in resolution
^KT-66313 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
`@Suppress` annotation has `VALUE_PARAMETER` target, so when a property
in the primary constructor is annotated with `@Suppress` it sticks
to the parameter. But the suppression should work for all diagnostics
reported on the parameter **and** the property
^KT-66258 Fixed
A Kotlin interface can have abstract members regardless of its modality. However, this invariant was previously ignored by FIR checkers. As a result, false-positive `ABSTRACT_<MEMBER>_IN_NON_ABSTRACT_CLASS` errors were being reported in explicitly non-abstract interfaces.
This commit makes a relevant FIR utility used by relevant FIR checkers aware of the aforementioned invariant.
#KT-66260 Fixed
Nikita Bobko