<div dir="ltr">Hi Arthur,<div><br></div><div>that's a valid concern. It has been discussed in the thread "[cfe-dev] RFC: Extend clang-format to support more/all C-like languages". Doug's conclusion was "I think this is a great direction so long as any lexer changes required are small, relatively isolated, and don't impact performance in our normal compilation path."</div>
<div><br></div><div>Nico</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 4:53 AM, Arthur O'Dwyer <span dir="ltr"><<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm being nosy here, but... What's the rationale for having<br>
clang-format understand Java syntax, when libclang itself doesn't<br>
claim to understand Java?  It seems like a *prerequisite* for this<br>
kind of work is to implement a Java parser... and is that really a<br>
goal of the Clang project?<br>
<br>
Java also has many keywords that aren't in C++ (yet), such as<br>
"abstract", "extends", "final" in weird* positions, "finally",<br>
"import", "native", "package", "throws", "transient"... and the "<<<"<br>
and ">>>" operators. You're not planning to hack up clang-format with<br>
ad-hoc cases for *all* of these, are you?<br>
<br>
Who's using clang-format on Java code, and why?<br>
<br>
–Arthur<br>
<br>
[* – By which I mean "saner than C++11's syntax", of course. :) ]<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Nov 20, 2013 at 8:32 AM, Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> wrote:<br>
> On Wed, Nov 20, 2013 at 4:03 PM, Daniel Jasper <<a href="mailto:djasper@google.com">djasper@google.com</a>> wrote:<br>
>>><br>
>>> +<br>
>>> +TEST_F(FormatTest, UnderstandsJavaScript) {<br>
>>> +  verifyFormat("a === b;");<br>
>>> +  verifyFormat("aaaaaaa === b;", getLLVMStyleWithColumns(10));<br>
>><br>
>><br>
>> How is this the correct format? Wouldn't we expect a break before "b"?<br>
><br>
><br>
> This need some work still, this patch just stops clang-format from breaking<br>
> the code by inserting a space inside these operators. I'll add a FIXME to<br>
> the test and a commented out test with the correct formatting.<br>
><br>
>><br>
>><br>
>>><br>
>>> +  verifyFormat("a !== b;");<br>
>>> +  verifyFormat("aaaaaaa !== b;", getLLVMStyleWithColumns(10));<br>
>>> +}<br>
>>> +<br>
>><br>
>><br>
>> Also, I think these tests are not sufficient. What if the LHS of one of<br>
>> these operators needs to be broken over multiple lines (there is a whole lot<br>
>> of logic of what happens to the RHS then)?<br>
><br>
><br>
> I'll add more complex tests (probably, commented-out, as we don't get this<br>
> quite right yet).<br>
><br>
>> I think we actually might need to merge the tokens.<br>
><br>
><br>
> I was thinking about this. What if we just "hide" the "=", so that<br>
> clang-format thinks there's just == or !=? I don't think we need to have any<br>
> logic specific to javascript identity operators.<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
><br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div>