This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
This is to record the red->green change in behavior between K1 and K2,
when K2 correctly handles resolution/inference of an extension function
with definitely non-nullable type.
Previously, it was led to plainly adding NullableType <: T constraint
which silently led to successful call completion.
What is suggested is just marking such initial constraint
as unsuccessful.
In K1, the error was reported just via additional type checking
mechanism being run after call completion.
^KT-58665 Fixed
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
1. this should've been only done if the language feature for validating
that is disabled;
2. that feature probably won't matter by the time FIR is stable;
3. it only worked because type enhancement of type arguments is broken
anyway - a more correct hack would be to provide a custom
ConeTypePreparator.
Denis.Zharkov