Result of the `checkNotNull` calls should always be a non-nullable
values.
The simplest idea how to acheive it is adding not-nullable Any bound
to the type parameter declaration.
Existing comment stating about impossibility of such bound seems to be
not 100% correct because it doesn't take into account presence of
definitely-non-nullable X & Any types that allow described case with
nullable generic.
^KT-55804 Fixed
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
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
This fixes an issue where an actual class from an intermediate module
has more supertypes than its expect declaration which leads to a
false-positive resolution error because a type reference resolves to the
expect class. The fix is to sort the dependencies topologically from
"most actual" to "most expect" when creating the list of symbol
providers.
#KT-57369 Fixed
Basically, this commit reworks eraseToUpperBound* stuff
Instead of a bunch of vague flags, we introduce two modes
(rawTypes/intersection emptiness checker) which defined those flags.
Also, it makes choosing `eraseArgumentsDeeply` option always because
that how it works in K1 and also use invariant projection inside
`eraseArgumentsDeeply` for raw types for the same reason.
^KT-57198 Fixed
These tests won't be FIR_IDENTICAL after the next commit. That's why I
split them prematurely. This allows me to have a nicer diff in `2/2`
commit.
In scope of KT-15470
Review: https://jetbrains.team/p/kt/reviews/9250
so the check is functionally the same as in K1.
#KT-57064 fixed
#KT-57065 fixed
One of the tests introduced here (javaMappedCtors) revealed an
additional issue, filed as KT-57368
The idea of the fix is just unwrapping flexible version of type alias,
before creating a not-nullable version for safe-call subject.
Otherwise, it was remained to be JsExpressionResult after applying
makeConeTypeDefinitelyNotNullOrNotNull (and the type is still nullable)
^KT-57190 Fixed
During implicit body resolve phase, we can encounter a reference to a
not yet resolved Kotlin class that inherits a synthetic property from a
Java class. In that case, resolve the return type in
FirSyntheticPropertiesScope.
#KT-57166 Fixed
Roman Efremov