^KT-44055 Fixed
It's possible only if there is a callable reference among subcalls which go though the old type inference (and the error for uninferred type parameter wasn't reported)
Example from
box/inference/coercionToUnitForLambdaReturnTypeWithFlexibleConstraint
// FILE: TestJ.java
public class TestJ {
public static <T> In<T> materialize() { return null; }
}
// FILE: test.kt
class In<in T>
fun <T> inferred(e: In<T>?, l: () -> T): T = l()
fun box() {
inferred(TestJ.materialize<Unit>(), { null })
}
`materialize` has flexible type, both for `In<T>` and `T`.
When analyzing `{ null }`, collected type constraints include:
ft<Unit?, Unit> <: T (from ft<In<ft<Unit, Unit?>>, In<ft<Unit, Unit?>>?>)
By allowing the lower bound of flexible type, FIR resolution can visit
`{ null }` with the expected type Unit, which will lead to proper
coercion to Unit at the end.
Namely, remove incorporation “otherInsideMyConstraint” to eliminate
constraint system redundancy and produce a potentially very large number
of constructs.
Instead, introduce not so “spreadable” incorporation during variable
fixation (equality constraint with result type into other constraints).
^KT-41644 Fixed
^KT-42195 Fixed
^KT-42920 Fixed
^KT-42791 Fixed
^KT-41741 Fixed
Motivation:
- drop getArguments from type context as a duplicate of getArgumentList
- reduce the number of collection allocations in getAllDeeplyRelatedTypeVariables
Additional minor improvements, test data fixes
Repeat the logic of KotlinConstraintSystemCompleter in ConstraintSystemCompleter.
Implement additional context operations required for updated lambda completion algorithm.
Without settings common inference components require additional parameters
to be passed explicitly from components not shared between FIR and FE10.
Proper configuration can be postponed in FIR, defaults are good enough for now.
^KT-42080 In progress
Helps fixing to more specific type in the following situations:
Type1 <: Var1
Var2 <: Var1
Var2 <: Type2
Type1 and Type2 may also be nullable and non-nullable versions of the same type.
Note that no additional constraints can be inferred from such constraints before fixation.
Resulting types for variables will always Type1 and Type2 may also be nullable and non-nullable versions of the same type.
Fixing Var1 first will make Var2's type more specific while fixing Var2 first
will make Var1's type less specific. The first is preferrable in general.
Victor Petukhov