fix checking for intersection types in CheckIncompatibleTypeVariableUpperBounds
we need this resolve, because getEmptyIntersectionTypeKind under
the hood uses org.jetbrains.kotlin.resolve.checkers.EmptyIntersectionTypeChecker.computeEmptyIntersectionEmptiness
which uses computeByHavingCommonSubtype where we have
isFinalClassConstructor() call, so we need to resolve to STATUS phase
to get the correct modality
^KT-56543
The compiler should only report diagnostics for
comparisons over builtins and identity-less types,
other incompatibilities should be reported
via inspections.
It's ok that in `equalityChecksOnIntegerTypes`
instead of `EQUALITY_NOT_APPLICABLE_WARNING` we get
`EQUALITY_NOT_APPLICABLE`, because
`ProperEqualityChecksInBuilderInferenceCalls`
is already active by default.
This change also replaces the notion of a representative superclass
with the least upper bound.
This makes complex types like
intersection/flexible transparent to
RULES1-based compatibility checks.
One way to look at it is to think
that this is an automatic way of handling
type parameters: automatic picking of
"interesting" bounds, and checking them against one another.
Note that `TypeIntersector.intersectTypes`
for `Int` and `T` where `T` is a type parameter
may return both `{Int & T}` or `null`
depending on `T`-s bounds. At the same time,
for type parameters `T` and `K` it will
always return `{T & K}`.
`ConeTypeIntersector.intersectTypes`, on the
other hand, will always return `{Int & T}`
irrespectively of the bounds. Meaning, the two
intersectors differ in corner cases.
`lowerBoundIfFlexible` call in `isLiterallyTypeParameter` is backed by
the `equalityOfFlexibleTypeParameters` test.
^KT-35134 #fixed-in-k2
^KT-22499 #fixed-in-k2
^KT-46383 #fixed-in-k2
This is the way it works in K1.
See `OverloadingConflictResolver.kt:345`.
^KT-57568 Fixed
Merge-request: KT-MR-9395
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Why did the problem existed?
At first, lambdas were analyzed with suspend function expected type,
because it's the WHEN-case and we propagate expected type info to
the branches.
Then, after the lambdas was introduced to the containing inference
system, we're creating ResolvedLambdaAtom using the information
from analyzed lambda's shape, but didn't use known lambda resulting
type (from which we might infer FunctionTypeKind).
So, the fix is just using that already obtained information.
^KT-57446 Fixed
The only case when behavior is change is described at
computeNonTrivialTypeArgumentForScopeSubstitutor
The idea is to avoid depending on the presence of @UnsafeVariance
and instead approximate captured types in covariant argument positions
before building substitution scopes
It's correct because for Captured(*) <: Supertype,
Out<Captured(*)> <: Out<Supertype> and when we've got @UnsafeVariance
value parameters at Out, it's ok to allow passing Supertype there.
^KT-57602 Fixed
^KT-54894 Fixed
Overriding equals, hashCode, toString and any other member that is not
expect does not require satisfying the rules of expect-actual matching.
#KT-57381 Fixed
Dmitrii Gridin