On Wed, Jul 9, 2014 at 11:16 AM, Aaron Ballman <aaron.ball...@gmail.com> wrote:
> On Wed, Jul 9, 2014 at 1:53 PM, Mark Heffernan <meh...@google.com> wrote: > > On Wed, Jul 9, 2014 at 7:42 AM, Aaron Ballman <aaron.ball...@gmail.com> > wrote: > >> I wonder how horrible it would be to simply canonicalize based on > >> compiler options when pretty printing, and skip this field entirely. > >> Eg) when CUDA is on, pretty print does not emit the parens. When CUDA > >> mode is off, it does emit the parens. Yes, this isn't *exactly* what > >> the user wrote, but the semantics are identical either way. > > > > It would be nice to get rid of the ValueInParens ugliness. One idea > > might be to consider the form with parentheses an error when compiling > > for cuda and the form without parentheses an error when compiling for > > !cuda. Then the parentheses can be emitted based only on whether cuda > > mode is enabled and we don't have to worry about the pragmas being > > silently transformed from one form to the other when printing out the > > ast. > > That would work, but it would be at the expense of the user's > experience (and some compatibility with other compilers). I guess my > question really boils down to whether pretty printing is important > enough to warrant this sort of hackiness, and I don't think it is (we > have other, existing pretty printing issues which I think are of > higher priority). Richard, do you have thoughts or ideas? 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. How about modeling the two options as either an IntegerLiteral or an IntegerLiteral within a ParenExpr?
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
