This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type
For a class literal Type::class we are resolving Type as a constructor,
getting all diagnostics (about missing arguments, for example) and then
just not committing this trace with errors
#KT-37626 Fixed
It's not clear how one should rollback _all_ resolution results if
there is inapplicable call. Ideally, such calls should not be available
in coroutine block but for now, to have backward compatibility, we'll
just reanalyze coroutine block as a usual lambda if there is at least
one such call.
As a result, also remove diagnostic about non-applicable call as it
become useless with current reanalysis
#KT-37061 Fixed
#KT-32097 Fixed
#KT-32203 Fixed
#KT-35306 Fixed
#KT-36202 Fixed
#KT-36220 Fixed
#KT-32654 Fixed
In this test `kotlin` was resolved to the extension
`val Class<T>.kotlin` because it was saved in builder-inference.
Usually, it's fine, but not for qualified expressions as they have
fallback resolve in case of error
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Reported diagnostics from the call checkers didn't get to a top-level
trace, if an intermediate wrapping call was a lambda call.
Use of the top-level trace in call completer is a workaround for
the unreliable commit order of common calls' temporary traces.
^KT-33542 Fixed
There are no `DEBUG_INFO_MISSING_UNRESOLVED` diagnostics for this test
if one runs it under LV=1.2. These diagnostics are not crucial
for the test (especially for version 1.2), so use it only with
the latest stable version
Plus, reuse test-data to check behavior in new inference
This call have interesting rules for resolution, see
`KtQualifiedExpression.elementChain` function and it's usages:
resolution results for such call can be omitted and be replaced with
some other information, while diagnostics will be reported from
builder-inference.
To mitigate this problem, we'll just skip this call from builder-inference
as such calls can't have type parameters anyway
#KT-32094 Fixed
Mikhail Glukhikh