The module is configured to run a bunch of test suites defined as API pairs. Currently those are `CURRENT API` – `CURRENT IMPL`, `CURRENT API` – `1.9.20 IMPL`, `1.9.20 API` – `CURRENT IMPL`
^KT-61860 In Progress
... with metadata dependencies. As it can cause unexpected version
downgrades.
This change restores behavior that existed previous versions. While
the separation between different source set trees remained.
The proper implementation should be done as part of KT-66375.
Related tests that were verifying the fact that platform dependencies
are also resolved consistently is ignored with reference to KT-66375
^KT-66372 Verification Pending
^KT-66154 Verification Pending
^KT-66375
This way it is easier to understand where `notifyAnalysis*`
methods were called. Also, in K1, we are not including
`checkKotlinPackageUsageFor*` in the analysis time.
`recordAssignments` merges properties into all parents which is
redundant work in the case of empty `VariableAssignments`.
This redundant work leads to critically poor performance in cases
with many local declarations.
^KT-66416 Fixed
`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
Otherwise, bootstrapping fails.
This condition is `false` because of
`require(this is ConeKotlinTypeProjection)`,
since `ConeKotlinTypeProjection` is its
sibling, not a subtype.
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).
Most probably it was there just to guarantee
that if `argument` is not a smartcast
expression then this property is exactly the
same thing as `originalType`, but it seems
there's not much point in that as none of
the tests fail.
`lowerThanBound()` was renamed to:
- draw attention to its corner cases
- make its single usage less cryptic
We may want to reserve the pretty name for
a function that, for example, returns `true`
if `argument` suits all the bounds.
Similarly, `canHaveSubtypes()`
does some questionable logic in case of
`INVARIANTxINVARIANT`: some hypothetical
`Inv<Foo>` doesn't have subtypes so
checking "Foo has subtypes strictly above
Nothing || Foo has supertypes strictly below
the parameter bounds" doesn't seem correct.
`Foo` may have some, but `Inv<them>` are
not related to `Inv<Foo>`.
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
Alexander.Likhachev