<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 9, 2014 at 11:16 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron.ballman@gmail.com" target="_blank">aaron.ballman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jul 9, 2014 at 1:53 PM, Mark Heffernan <<a href="mailto:meheff@google.com">meheff@google.com</a>> wrote:<br>

> On Wed, Jul 9, 2014 at 7:42 AM, Aaron Ballman <<a href="mailto:aaron.ballman@gmail.com">aaron.ballman@gmail.com</a>> wrote:<br>
>> I wonder how horrible it would be to simply canonicalize based on<br>
>> compiler options when pretty printing, and skip this field entirely.<br>
>> Eg) when CUDA is on, pretty print does not emit the parens. When CUDA<br>
>> mode is off, it does emit the parens. Yes, this isn't *exactly* what<br>
>> the user wrote, but the semantics are identical either way.<br>
><br>
> It would be nice to get rid of the ValueInParens ugliness.  One idea<br>
> might be to consider the form with parentheses an error when compiling<br>
> for cuda and the form without parentheses an error when compiling for<br>
> !cuda.  Then the parentheses can be emitted based only on whether cuda<br>
> mode is enabled and we don't have to worry about the pragmas being<br>
> silently transformed from one form to the other when printing out the<br>
> ast.<br>
<br>
</div>That would work, but it would be at the expense of the user's<br>
experience (and some compatibility with other compilers). I guess my<br>
question really boils down to whether pretty printing is important<br>
enough to warrant this sort of hackiness, and I don't think it is (we<br>
have other, existing pretty printing issues which I think are of<br>
higher priority). Richard, do you have thoughts or ideas?</blockquote><div><br></div><div>The language-mode-based switching is what we do when pretty-printing _Bool vs bool, and __wchar_t vs wchar_t, but it's horrible and I'd prefer to not add more horrible to the mix.</div>
<div><br></div><div>How about modeling the two options as either an IntegerLiteral or an IntegerLiteral within a ParenExpr?</div></div></div></div>