[PATCH] Add support for unroll pragma

[Richard Smith]

On Wed, Jul 9, 2014 at 11:16 AM, Aaron Ballman <aaron.ballman at gmail.com>
wrote:

> On Wed, Jul 9, 2014 at 1:53 PM, Mark Heffernan <meheff at google.com> wrote:
> > On Wed, Jul 9, 2014 at 7:42 AM, Aaron Ballman <aaron.ballman at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140716/9d50ab55/attachment.html>