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 <[email protected]> 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/ > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
