Report an error that inference will change and type has to be provided
manually in other language versions, since the current behavior is an
unsoundness that can cause runtime NPEs while the new behavior may
silently change overload resolution.
^KT-30054 Fixed
It's reported on receivers in extension function calls with stub type,
as such calls can shadow members of finalized stub types causing
change of resolve when corresponding type argument specified explicitly
It works by checking extension receiver during call resolution parts run
That way we can easily detect if we found an extension applicable to
stub receiver and report call diagnostic for it
KT-53739
Let's call builder lambdas (BL) a lambda that has non-fixed input type
projection at the moment of lambda arguments analysis, such lambdas
is a subject to be analyzed with builder inference
Due to bug in constraint system joining algorithm, currently system
of two or more such lambdas may lead to unsound type inference
Diagnostic added here should be reported in case when there are two
BL that shares a common constraint system, while not annotated with
@BuilderInference, as a protection against aforementioned bug
It's reported by ConstraintSystemCompleter when such situation has
occurred during builder inference phase, it is the same place that
decides wherever lambdas is subject to builder inference or not
KT-53740
In K1, upper bound violated causes candidate to have lower applicability
due to constraint errors, in K2 however constraint errors has to be
reported explicitly
The original case provoked forking a constraint system which isn't supported in K1 (K2 only). If the captured type is recursive, then type parameter's upper bounds may break subtyping due to substitution the current captured type again, into a recursive type parameter.
Note that we already have special logic for recursive captured types. See `isTypeVariableAgainstStarProjectionForSelfType`.
^KT-52782 Fixed
It leads to further infer type variable into those upper bounds which is forbidden
Substituted upper bounds is ok because specific substituted types came from constraints of other proper positions, or if specific substituted type is from declared upper bound too, then there should be another declared upper bound with no substitution
^KT-51464 Fixed
^KT-47986 Fixed
Sometimes, it might be called before type parameter bounds are initialized
or even before the symbols are bound to FIR
In such cases, we just assume it makes sense to create DNN there
That issue might be fixed via changing
TypeVariableMarker.shouldBeFlexible at ConeConstraintSystemUtilContext
but this and some other tricks have been added because of incorrect
handling of constraints where type variable has a flexible bound
^KT-51168 Fixed
pyos