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
Previously, enum entries were treated by the data-flow subsystem similar
to other class/singletons. As a consequence, calls like
'Enum.ENTRY.property' had IdentifierInfo of 'property'.
However, specially for enum entries, descriptor of 'property' is one and
the same for all entries. It means that from the data-flow point of
view, 'Enum.ONE.property' and 'Enum.TWO.property' are *one and the same
data-flow values*.
It could obviously lead to some bogus smartcasts, so this commit
introduces separate IdentifierInfo.EnumEntry and uses it to build proper
qualified values.
^KT-20772 Fixed
The issue here is that OI infers correct types for (k, v) destructing
declaration, while NI infers errors for them. That happens because NI
resolves iterator() on nullable 'm', but rightfully reports it as
unsuccessful, while OI somehow manages to resolve it to success (and
thus getting nice expected type, allowing destructing declaration to be
resolved in a proper types).
This commits introduces testdata changes, where NI behaviour strictly
improved, after several previous fixes.
For some tests, just WITH_NEW_INFERENCE directive was added. It
indicates, that some of previous commits first introduced error in that
test, and then some other commit fixed it (netting no overall testdata
change). It is preferrably to keep those annotations until we will
migrate to NI completely, to prevent unexpected regressions.
This test introduces very special (for current implementation) case,
when we have smartcast indirectly, via some reified type parameter.
It covers recursive call inSmartCastManager.checkAndRecordPossibleCast(),
which wasn't previously covered by any test in testbase.
Denis Zharkov