#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
New resolution applicability is needed in cases when error is found,
but candidate still should be selected. Currently there are two cases,
when this behaviour is required:
- unstable smartcast (choose candidate with non-nullable parameter)
- unknown lambda parameter type (against non-functional expected type)
KT-36264
There are several issues with unsafe desugaring for convention calls.
Proper fix is not implemented here (see design proposal KT-30872).
This commit only applies the old logic in the new inference.
^KT-30695 Fixed
Expression will be checked against expected type later.
Theoretically, this is not very good, but it aligns with the old
inference, plus it helps avoiding multiple type mismatch diagnostics.
This test was originally written with fix for KT-22379
Lately, fix was proven to be wrong and reverted (KT-27084), which made
this test fail.
Correct solution here would be to mute test with link to YT issue, but
unfortunately we don't have infrastructure to mute tests locally (yet),
which is a major issue because this tests is a part of very popular for
local smoke-testing test suite (DiagnosticTestsGenerated).
Equality of those values is crucial for intersecting data-flow info
coming from expressions like: 'this.x != null || other.x != null'.
Using 'ValueDescriptor' for equality is obviously wrong, because then 'this.x'
and 'other.x' will be treated as equal, leading to unsound smartcasts.
This commit adds proper overload of 'equals' to 'ESDataFlowValue' that
will compare them based on underlying 'DataFlowValue' (which already
distinguish those values)
^KT-27260 Fixed
Idea is to intersect similar smartcasts on similar properties coming
from *different* instances (something like
'this.x == null && other.x == null' ).
It checks that we distinguish subjects of such smartcasts properly.
Currently behavior is undesired, see KT-27260
This is effectively a revert of
447c127036, which was an (incorrect) fix
for KT-22379.
The bug was that we've cleared data-flow info for assigned variables
*after* knowledge that loop condition if 'false' was applied (we can
claim that if loop has no jump-outs). Therefore, we broke smartcasts in
the innocent code like that:
var x: Int? = null
while (x == null) {
x = readPotentiallyNullableInt()
}
// x should be non-null here
Commit reverts that "fix" for 1.3.0 and postpones deprecation until 1.4
KT-22379 Open
KT-27084 Fixed
simon.ogorodnik