[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