This fixes a scenario when INVISIBLE_REFERENCE is suppressed, but we
resolved to the wrong overload because when none of the candidates were
applicable, more or less the first one was chosen.
Because we call `fullyProcessCandidate` on the candidates, their
applicability can change which can lead to a situation where the
applicability of a ConeAmbiguityError is different to all its
candidates. The changes in coneDiagnosticToFirDiagnostic.kt account for
that, otherwise code like candidates.first { it.applicability ==
CandidateApplicability.UNSAFE_CALL } can throw NoSuchElementException.
#KT-57776 Fixed
It was working incorrectly, because we've been trying to fix
P1 variable to intersectTypes(String?, StubForP2) that should result
to String? because we've got stubEqualsToAnything enabled there,
but nullability was being chosen incorrectly because
`StubForP2.isNullableType()` returned false
NB: The code inside `is ConeTypeVariable` case wasn't working properly
because it always `lookupTag.toSymbol(session)` always returned null,
thus there was effectively five dead lines of code there.
^KT-57814 Fixed
^KT-57921 Related
The constructor with the required parameters may
not have been defined, and since JS/IR box tests
pass, it seems, we don't have to resolve
into anything meaningful. We could generate
the appropriate constructor like dynamic type
members are generated, but, again, K1 IR doesn't
even contain a delegating constructor call.
^KT-57809 Fixed
The change in `FirDiagnosticsHandler` ensures
`DEBUG_INFO_DYNAMIC` is still reported in
`FirPsiJsOldFrontendDiagnosticsTestGenerated.testConventions`.
Support `SPREAD_OPERATOR_IN_DYNAMIC_CALL` and
`WRONG_OPERATION_WITH_DYNAMIC`
Add a special annotation @JsExternalInheritorsOnly for marking
external interfaces and classes. The marked interface or class
can’t be a parent for non external interfaces, classes or objects.
^KT-57423 Fixed
In K1 .isFun is always false for Java classes, so extra check
is added for that. This is not needed for K2, because .isFun is
true for all Java classes. Here it is not necessary to check
that interface has only one method, because such check will be
done in the place where interface implementation is created.
^KT-39362 Fixed
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
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
Denis.Zharkov