This affects methods like List.getFirst/getLast where it was decided
to keep them hidden but to make them visible on overrides like
ArrayList or LinkedList.
The goal is to prevent a breaking change since some implementations
like LinkedList had this method before JDK 21.
#KT-65438
Suggest removing explicit type arguments when the upper bound is a
captured type since the only way to satisfy the upper bounds is
by letting the type variable be inferred to its bound.
#KT-65681 Fixed
- Handle flexible types in recursion check
- Handle intersected supertypes separately
- Make check when not to approximate captured types in type argument
position more fine-grained.
Only apply it to case when the captured type is replaced by a star
projection.
All other cases are handled by recursive calls to
approximateCapturedType
#KT-65377 Fixed
This only affects delegation operators as well as the for-loop-related
next and hasNext operators.
All the other operators worked correctly before.
In K2, the previously mentioned operator calls will be flagged with a
deprecation error and will become and error in 2.1.
#KT-59782 Fixed
... if the delegate happens to be a function call whose second
argument is a callable reference but not actually a provideDelegate
call.
The fix is to ensure that the call is _actually_ a desugared
provideDelegate call.
This fixes a CCE in a case where the delegate expression is a regular
function call and the second argument is a callable reference.
#KT-65165 Fixed
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
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 is necessary to prevent exponential growth of the attribute
structure.
Since we usually care for the most inner value of a
ConeAttributeWithConeType like EnhancedTypeForWarningAttribute, this
shouldn't alter any behavior.
The error-level enhancement is kept as warning-level and a new
LanguageFeature is introduced to turn the warning into an error.
#KT-63208 Fixed
#KT-63209
(cherry picked from commit 371b1eb3d5)
This is required for EnhancedTypeForWarningAttribute because scopes
should not be reused between cone types with different values of
this attribute.
#KT-63208
(cherry picked from commit 9189154cae)
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
This is in preparation of a future commit, where captured types won't be
approximated anymore after completion.
Consider a case like
class Box<T>(val value: T)
interface Foo<T> { fun bar() }
fun test(x: Box<out Foo<*>>) {
x.value.bar()
}
The type of `x.value` will be `CapturedType(out Foo<*>)`.
Note that capturing only applies to the top level, i.e., nested
projections are not captured.
That's why it becomes necessary to support capturing of captured types,
otherwise the star projection in `CapturedType(out Foo<*>)` is not
properly captured in the receiver of the call `x.value.bar()`.
#KT-62959
The error-level enhancement is kept as warning-level and a new
LanguageFeature is introduced to turn the warning into an error.
#KT-63208 Fixed
#KT-63209
This is required for EnhancedTypeForWarningAttribute because scopes
should not be reused between cone types with different values of
this attribute.
#KT-63208
This commit gets rid of the redundant typeApproximatorConfiguration
in Fir2IrTypeConverter and uses the type approximator for captured
types instead of the manual approximation used before.
This fixes the nullability of approximated captured types, which fixes
a runtime error in WASM.
This also brings K2 IR closer to K1 IR in one test.
#KT-64261 Fixed
Previously, we would ignore the candidate with the non-smartcasted
receiver if they have the same symbol.
Now we prefer them when they're visible or when the smart cast changes
the nullability.
This is required for the following commit where candidates from the
original scope in presence of smart cast will not be ignored if they're
the same symbol.
Static scope is checked first during resolution
(scopes are in reverse order).
This fixes a difference between how K1 and K2 resolve annotations.
#KT-63249 Fixed
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
Kirill Rakhman