[PATCH] clang-format: Space and triple angle braces

[Jacques Pienaar]

If CUDA language option is enabled then
A<A<A<int>>> a;
gets changed to
A < A < A < int >>> a;
as >>> at the end is no longer 3 tokens but 1. I could modify the
parseAngle (I believe) function to address this case though. The majority
of uses would be for regular C++, so enabling CUDA language option by
default would seem to benefit me but possibly causing others headaches, so
I went for a route where the opening triple angle bracket is retained as is
in as direct a manner as possible while affecting as few other code paths
as possible.

The importance is in the CUDA code generation side. foo<< <1,1>>>() would
not be recognized as a CUDAKernelCallExpr. So an input program that
compiled would not compile post formatting.

Would it be OK to merge the tokens in the following case?
friend std::ostream& operator << <T> (std::ostream&, const Self&);
That was pretty much the only other usage for three open angle brackets I
saw. Currently I think it would be merged, so that would not change but I
want to double check. If so, then I'll follow your suggestion and add those
tests thanks.


On Tue, Dec 30, 2014 at 6:43 AM, Daniel Jasper <djasper at google.com> wrote:

> We don't generally want to use the spacing in the input to matter for the
> output. Is this really important? What would be the downside of using
> language options?
>
> Also, just controlling the space might not be sufficient as clang-format
> also might go ahead break between the tokens. Generally, it might be better
> to actually merge the tokens (as is done for the === operation in
> JavaScript), as these should be considered to be a single token.
> Alternatively, you need to at least control CanBreakBefore for these and
> add tests for BreakBeforeBinaryOperators set to All and None.
>
>
> http://reviews.llvm.org/D6800
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141230/b8c2a810/attachment.html>