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.
This commit includes a lot of minor changes in testdata: new infrastructure
requires that each test file in one testdata file in one module must
have unique name, but a lot of existing spec tests didn't satisfy
this requirement
Before this commit, we used type after smart cast both for original
FirThisReceiverExpression and for wrapping FirExpressionWithSmartCast.
However, this makes FIR2IR implicit cast generator work incorrectly
(it decides not to insert implicit cast because original type is the same).
After this commit, expressions have different types and implicit cast
generator works properly.
In FIR, the source of FirFunctionCall is set to call's selector.
In practice, sometimes (e.g. for DEBUG_INFO_CALL)
we expect the selector as the source,
and sometimes (e.g. for DEBUG_INFO_EXPRESSION_TYPE)
we expect the whole qualified call as the source.
Also, some diagnostics, like REDUNDANT_CALL_OF_CONVERSION_METHOD,
are expected to be reported on a selector, not on a whole call.
At this moment we ignore the problem & just don't support
DEBUG_INFO_EXPRESSION_TYPE for qualified calls.
In init block or property initializers,
for `val x` declared in primary constructor,
`x` reference is now resolved to property, not to parameter.
So we need two different scopes for primary constructor,
one for 'pure' parameters and another one for all parameters,
including val/var ones.
#KT-42844 Fixed
There is introduced algorithm of resolution with jumps: before
resolution of some class we resolve all status of members of its
supertypes, so we can properly determine inherited visibility
and modifiers
Several tests are affected by the usage of fixation direction calculator in FIR.
Restored to mimimize test data changes.
It is unnecessary in FE10 because a type variable with unknown type
is inferred into an error type, but affects test data in FIR where
Nothing/Any is selected by direction (as a temporary measure).
CR candidate in spec test is Unresolved in FIR because top-level CRs are resolved as call arguments.
Resolution ambiguity is also present in FE10 when CR is wrapped into an id call.
Jinseong Jeon