The fix is a bit hacky, but it's very simple. In addition, it still does
not handle the case where the receiver is a lambda function. But such
case seems to be fairly rare in practice.
For a qualified name like `foo.bar.Outer.Inner`, FIR represents it as
one atomic FIR element. Hence, to properly resolve these names to the
corresponding package and class, we need some additional work.
no `inline` flag for serialized properties.
In order to test this, I added the changes to FirRenderer to make sure
the flag is not loaded. However, this revealed that the `inline` status
was propagated upward to the `FirProperty` during raw FIR building,
causing test failures.
I removed the upward propagation for `inline`. I also removed it for
`external` because it is incorrect: `external` on properties (used in
JS) should be separate from `external` on accessors (used in JNI
interop for JVM). The `external` flags are also serialized separately
for properties and accessors.
As part of this change, we also extend the usage of RealVariable in more
places during DFA. Now mutable properties, property with custom getters,
delegated properties, etc are also treatd as a `RealVariable`. In
general this is needed in order to carry out smartcast computation in
order to report `SMARTCAST_IMPOSSIBLE`. It seems to also have side
effects that improves behavior of some test files.
As part of this change, we also extend the usage of RealVariable in more
places during DFA. Now mutable properties, property with custom getters,
delegated properties, etc are also treatd as a `RealVariable`. In
general this is needed in order to carry out smartcast computation in
order to report `SMARTCAST_IMPOSSIBLE`. It seems to also have side
effects that improves behavior of some test files.
Make it work just the same as the analogue from FE 1.0
This change is necessary since many tests start failing after
we began reporting diagnostics after call completion
The change in FirDeclarationUtil is needed because in case of unsigned
types loaded from the standard library, the primary constructor for some
reason is not the first, but the second in the list of constructors.
This new kind of expression encompasses the nullability of the original
expression after null check (or equivalent `is Nothing?` check).
Unlike FirExpressionWithSmartcast, this expression won't be materialized
during conversion to backend IR. Also, Nothing? is discarded when
computing the intersection of possible types from smartcast info.
In that way, Nothing? is not used during resolution, while such
smartcast info is stored in it (and the expression kind itself).
Tianyu Geng