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.
See `checkStatementType`, we return `null` to reduce count of errors.
Also, note that named function which is used as last statement in lambda
doesn't coerce to Unit, this is a separate bug and will be addressed later,
see #KT-25383
#EA-121026 Fixed
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.
Parameters/vals with an immediate initializer (which we assume is a
rather common situation) do not require any kind of complicated CFA
- Unused vals can be simply determined by linear traversal of
the pseudocode
- Definite assignment is a bit more complicated: a read-instruction of val
can be considered as a safe if it's located *after* the first write in
the pseudocode. It works almost always beside the case with do/while
(see the test changed). This case will be fixed in the further commits
The test for kt897.kt will also be fixed further, all other changes
might be considered as minor as they mostly change diagnostics for
already red code
Last declaration in block is resolved in DEPENDENT mode because it has
influence on return type and therefore fake call for destructuring declaration
wasn't completed (see `getBlockReturnedTypeWithWritableScope`)
Now we resolve fake call for destructuring declaration in INDEPENDENT
mode as it doesn't have effect on return type
#KT-15480 Fixed
Forbid underscore-only (_, __, ___, ...) names as callees and as types.
If CHECK_TYPE directive is on, filter out UNDERSCORE_USAGE_WITHOUT_BACKTICKS messages.
It's needed when declarations are parsed as a part of previous expression
(see tests)
Currently we apply this kind of recovery in a conservative way,
only when declaration starts at the next line, and while
the condition could be relaxed, there's no need to do this
#KT-4948 Fixed
#KT-7118 Fixed
Mikhail Glukhikh