This reverts commit bb6f466162.
Reverting the fix for KT-57417 as it causes failures in IntelliJ and
Space projects. May reintroduce fix after failures are investigated and
resolved.
When a property is implemented via class delegation, it should be
considered unstable for smart-casting. This is because it is unknown
what kind of stability the underlying class delegate property has. It
could be a stable property, or it could be implemented via a custom
getter and unstable.
^KT-57417 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
Instead, rely on the variable assignment analyzer to properly restrict
smart casts. This makes error messages more consistent, but otherwise
should have no effect.
In order to make resolution still work for members not available from
`Nothing`, we track the type without `Nothing?` and use that for
resolution instead.
The logic should clear back aliases as well. To ensure all back aliases
don't lose any information, statements on the original variable are
copied over to its aliases.
This directive anyway does not make test run twice with OI, and with NI
It only once run the test with specific settings (// LANGUAGE)
and ignores irrelevant (OI or NI tags)
Previously if an unsafe call is to an overloaded function, FIR checkers
report NONE_APPLICABLE. This change instead report them as UNSAFE_CALL
or its variants.
To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.
Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive
#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
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.
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).
Brian Norman