This commit ensures all the conversions inside the lambda expression
use the correct tree reference.
Otherwise, the problem arises in the
`toFirSourceElement()` call: if called form inside the
ExpressionsConverter, everything is OK, but calling it from inside
DeclarationsConverter will result in the wrong source text range.
This happens, because during the lambda expressions conversion a custom
ExpressionsConverter is created with the `lambdaTree` tree, but the
DeclarationsConverter continues to use the previous tree.
FE1.0 descpritor, PSI2IR, and JVM IR backend use that.
FIR2IR is also using that, which implies name "value" in RAW FIR
maybe has not been used anywhere.
In qualified expression like `foo().`, selector expression is null.
Because of that the whole expression was marked as an error FIR
expression, and `foo()` part was not resolved at all (including
arguments and everything else).
This commit fixes the problem by providing receiver's FIR expression
as an underlying expression for error FIR expression. That way
it will be seen by all resolve transformers and will be successfully
resolved.
^KTIJ-21484 Fixed
along with source lines mapping, allows to "emulate" usage of the
PSI files which allows to extract source file and line mapping info
on every stage from source element.
It makes sense to use this mapping for the error reporting too.
Previously (few commits earlier), it contained two versions
of receiver (lhs) generated separately for each desugaring version
that looked a bit redundant.
Now, at FIR building stage we just don't create desugaring sub-trees,
instead they are being built during bodies transformation and that seems
to be much convenient there, since we don't need to reverse-engineer
get-set-operator version to check if containing calls are successful
(as we just built those calls and retain them)
Semantically, this changes may only change how data flow works
for such statements (see changed compatibilityResolveWithVarargAndOperatorCall.kt)
^KT-50861 Relates
It's necessary to allow a?.b += v be interpreted as a?.(b += v)
But currently FirAssignmentOperatorStatement is not FirQualifiedAccess
^KT-41034 In Progress
The source is set on the alternative block but not the XXXAssign call.
BTW, the real source is incorrect shared among the FirAugmentedArraySetCall,
FirBlock, so this change uses a fake source for the FirBlock and the
FirFunctionCall. Using fake source does not seem to be necessary for
compilable code because in that case FirAugmentedArraySetCall is
transformed to either a FirBlock or a FirFunctionCall. But it's needed
for ambiguous code where such transformation fails. In this case, all
three FirElements are present and they should not share the same real
source.
In addition, this change also sets a fake source for the `get` call of
the array access to the left hand side of the operator. For example,
`m[a] += 1` where `m` is some custom map implementation that does not
return `null` from `get`. The (fake) source of the synthetic `get` call
in FIR is now `m[a]`. This is handy because the analysis API will
resolve `m[a]` to the `get` call.
Roman Golyshev