<div dir="ltr"><div>If CUDA language option is enabled then<br></div><div>A<A<A<int>>> a;<br></div><div>gets changed to</div><div>A < A < A < int >>> a;<br></div><div>as >>> at the end is no longer 3 tokens but 1. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important;background-color:rgb(255,255,255)">I could modify the parseAngle (I believe) function to address this case though</span>. 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.</div><div><br></div><div>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. </div><div><br></div><div>Would it be OK to merge the tokens in the following case?</div>friend std::ostream& operator << <T> (std::ostream&, const Self&);<br><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 30, 2014 at 6:43 AM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br><!--
--><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
<br>
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.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D6800" target="_blank">http://reviews.llvm.org/D6800</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</blockquote></div><br></div>