[Mono-dev] Question about LiftedBinaryOperator in mcs source

Marek Safar marek.safar at gmail.com
Thu Jan 31 18:07:40 UTC 2013


Hi,

I'm working on project that uses Mono as its C# parser. It uses the AST
> that comes from calling "Resolve".
>
> I'm having trouble understanding what happens to LiftedBinaryOperator.
>
> In particular, this code seems strange:
>
>             if (left_orig is NullLiteral) {
>                 left = right;
>
> One of the effects of this assignment is that, if a user operator is
> involved, the corresponding UserOperatorCall will have "right" as both of
> its arguments.
> If I replace the assignment with, say:
>                 left = LiftedNull.Create (right.Type, left.Location);
> I get parse errors.
> It seems that at least one of the goals is to trigger a check for "left !=
> right".
>

This is kind of trick to simplify handling of comparisons which always end
up with constant result but are allowed by the language.

For example

bool b = false;
var x = null != b;

If you found a case where this breaks valid C# code, please fill a bug
report with C# example.


>
> Another mysterious thing I noticed is that, in the AST for code like:
> int i;
> int ?oi;
>
> i + oi;
>
> the AST is a LiftedBinaryOperator where "right" is an Unwrap with type int
> (this part I understand), while "left" is an EmptyCast with type "int?",
> which I find mysterious. It looks like the "EmitOperator" call casts it
> back to its original type:
>             if (left.Type.IsNullableType) {
>                 l = NullableInfo.GetUnderlyingType (left.Type);
>                 left = EmptyCast.Create (left, l);
>             }
>
>
Correct, that's just another wrap so we can use same emit operator routine.


> It would be great if you could explains how all this works.
>

All nullable handling is tricky especially cases involving user operators
mainly because C# spec is light on details about nullable handling and does
not match csc implementation quite few cases.

Sorry for late reply I somehow missed your email.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130131/7c1b9b13/attachment.html>


More information about the Mono-devel-list mailing list