K2 version runs like for 15s.
It became slow after PCLA (KT-59791) was implemented,
and the reasons for that is the presence of a lot of interconnected TV
which leads to O(NUMBER_OF_CONSTRAINTS*NUMBER_OF_VARIABLES)
asymptotic during constraint incorporation.
The test itself in any way doesn't represent some common BI use case,
so it seems reasonable to mute it temporary.
^KT-65005 Related
See callingOuterGenericClassConstructorWithSelfTypes.kt
Previously, for A<B>(""), we used substituted constructor
where `X` was substituted with `B` (or `A<X>.B`).
But when resolving the call for constructor, we use `X`
as a type variable of the call, thus in some positions
we used `X` as TV (Xv in the comments) and somewhere `X` as a type
parameter, thus leading to contradictions (see clarifying comment).
The idea of the fix is simply repeating of the regular (not delegated)
constructor call resolution:
- We substitute only type parameters of outer class
- All the declared parameters of the callee are being checked
through regular resolution & inference mechanisms.
NB: Diagnostic only being reported on arguments because there
when we add `String <: Any` constraint it fails due to existing
contradiction in the CS.
Without the argument/parameter the error is just being lost, but that's
a different story (seeKT-65224).
^KT-64841 Fixed
We are using `ConeKotlinType` instead of `FirTypeRef` to represent
that element type of vararg doesn't have any source. It has a type
that was inferred. If we try to specify a source, then we could
end up with the incorrect place for diagnostic.
#KT-59682 Fixed
This fixes a compiler crash
IllegalStateException: Captured type for incorporation shouldn't escape
from incorporation
The crash occurs when a captured type with status FOR_INCORPORATION
is two layers deep inside a captured type with status FROM_EXPRESSION.
We first check if approximation is required for the most outer captured
type in AbstractTypeApproximator.approximateCapturedType.
Then we encounter the second captured type with status FROM_EXPRESSION
in AbstractTypeApproximator.approximateParametrizedType.
At this point, we stop checking and miss the third captured type with
status FOR_INCORPORATION.
Unfortunately, we can't check recursively if nested captured types
need to be approximated because of types with recursive super types
(the original reason why the extra check was introduced).
That's why we restrict the second check to types with recursive
super types, effectively restoring the previous behavior for all other
types.
#KT-65050 Fixed
This fixes some type argument mismatch errors caused by a captured type
being approximated and then captured again.
Some places need to be adapted to work with captured types that
previously only worked with approximated types.
#KT-62959 Fixed
While reporting a diagnostic there seems to be correct because the
parameter type is ConeErrorType, the former fact is a bug
in PCLA that should be fixed soon
Previously, error types on those implicit parameters were being lost.
Changed test data is only partly here
(only parts that are considered to be correct).
Other ones (new green-to-red changes) should belong to the next commit
and will be fixed soon (as a part of PCLA).
Before this change `ARGUMENT_TYPE_MISMATCH` would complain that
`Y` "is not a subtype of" `Inv<Y>`, because the function would only
check immediate bounds of the type parameter `Y`. `chosenSupertype`
would be `X`, not `Inv<out kotlin/String>`.
^KT-60056
Before this commit, K2 always applied coercion-to-unit for
callable references if expected type was Unit, and actual non-Unit.
However, this may not work in case when actual return type is
a type parameter and it must be inferred into Unit.
In this commit we started to disallow coercion-to-unit
for references with synthetic outer call (~ top-level in K1)
AND a type parameter as a return type (both should be true to disallow).
This provides better K1 consistency,
while still keeping some broken K1 cases working in K2.
See also added comment in CallableReferenceResolution.kt.
#KT-62565 Fixed
Error arises from the fact that type substitution operation isn't
consistent when applied to captured types.
E.g.:
```
substitution = { A => B }
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_1>
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_2>
C<CapturedType(out B)_1> <!:> C<CapturedType(out B)_2>
```
Relates to KT-53749
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This commit actually does two things:
- Adds Any scope to stub type
- Makes CheckDispatchReceiver treat stub types
as non-null for the unsafe call check to make such candidates viable
Related to KT-59369
Previously, because we didn't handle flexible types properly in
prepareCapturedType, projections inside flexible types would only be
captured during subtyping with captureStatus=FOR_SUBTYPING
which would lead to the constraint type being wrongly approximated
(see ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint).
Fixing the capturing produced two kinds of false positive diagnostics:
1. In ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint we would get two instances of cone types
that are structurally equal and containing the same captured type.
However, because we only skipped subtyping if the types were
referentially equal, we would get a contradiction here.
The fix was to use structural equality instead, which should be okay
as the captured type instances are the same.
2. Reified type variables were inferred to captured types because
flexible arrays with captured upper bounds
(Array<Foo>..Array<Captured(out Foo)>?) were not properly approximated.
#KT-62609 Fixed
This commit handles subtle situation when K1 represents flexible type
arguments as just T..T?, but K2 does it as T&Any..T?.
This can provoke a type like Captured(*)&Any..Captured(*)?,
and before this commit we couldn't find recursion inside Captured(*)&Any.
This could lead to explosions inside type system and inference errors
#KT-60581 Fixed
Before this commit, we allowed access to outer class type parameters
during resolve of type parameter bounds of a nested class.
In fact, outer type parameters are accessible in this situation
only if it's an inner class (or a local class).
This commit forbids such a usage. In the earlier fix of KT-57209
the same was done for regular type reference resolve.
#KT-61459 Fixed
#KT-61959 Fixed
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
Denis.Zharkov