Use the receiver and context receiver types in addition to the property
name as cache keys for the synthetic property generation.
Also, fix logic that searches for accessor overrides by comparing
receiver and context receiver types.
Finally, let synthetic properties delegate their receiverParameter and
contextReceivers to their accessors.
#KT-65464 Fixed
#KT-66195
The following tests are failing with exceptions and will be fixed in the
following commits
j+k/testKjkPropertyAndExtensionProperty.kt
j+k/testKjkImplicitReturnType.kt
#KT-62118 Fixed
lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
outside of constructor.
In other words, when EXACTLY_ONCE lambda initializes non-static final
field of a class, the lambda has to be inlined, otherwise, backend
generated separate function of separate class for the lambda,
which lead to exception at runtime.
#KT-64854 Fixed
#KT-59906 Fixed
^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 way it's easier to reason about where
useless casts/is checks come from, because
everything is on the same screen.
`USELESS_CAST` disappeared from
`FirPsiJsOldFrontendDiagnosticsTestGenerated.testDynamicCastTarget`
because
`LanguageFeature.EnableDfaWarningsInK2`
is disabled, and previously it only
affected `FirCastOperatorsChecker`, but
not `FirUselessTypeOperationCallChecker`,
which felt like an unintended mistake.
A related issue: KT-50965
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
Mikhail Glukhikh