r195251 - Support for JavaScript === and !== operators.

Arthur O'Dwyer arthur.j.odwyer at gmail.com
Wed Nov 20 11:53:13 PST 2013


I'm being nosy here, but... What's the rationale for having
clang-format understand Java syntax, when libclang itself doesn't
claim to understand Java?  It seems like a *prerequisite* for this
kind of work is to implement a Java parser... and is that really a
goal of the Clang project?

Java also has many keywords that aren't in C++ (yet), such as
"abstract", "extends", "final" in weird* positions, "finally",
"import", "native", "package", "throws", "transient"... and the "<<<"
and ">>>" operators. You're not planning to hack up clang-format with
ad-hoc cases for *all* of these, are you?

Who's using clang-format on Java code, and why?

–Arthur

[* – By which I mean "saner than C++11's syntax", of course. :) ]


On Wed, Nov 20, 2013 at 8:32 AM, Alexander Kornienko <alexfh at google.com> wrote:
> On Wed, Nov 20, 2013 at 4:03 PM, Daniel Jasper <djasper at google.com> wrote:
>>>
>>> +
>>> +TEST_F(FormatTest, UnderstandsJavaScript) {
>>> +  verifyFormat("a === b;");
>>> +  verifyFormat("aaaaaaa === b;", getLLVMStyleWithColumns(10));
>>
>>
>> How is this the correct format? Wouldn't we expect a break before "b"?
>
>
> This need some work still, this patch just stops clang-format from breaking
> the code by inserting a space inside these operators. I'll add a FIXME to
> the test and a commented out test with the correct formatting.
>
>>
>>
>>>
>>> +  verifyFormat("a !== b;");
>>> +  verifyFormat("aaaaaaa !== b;", getLLVMStyleWithColumns(10));
>>> +}
>>> +
>>
>>
>> Also, I think these tests are not sufficient. What if the LHS of one of
>> these operators needs to be broken over multiple lines (there is a whole lot
>> of logic of what happens to the RHS then)?
>
>
> I'll add more complex tests (probably, commented-out, as we don't get this
> quite right yet).
>
>> I think we actually might need to merge the tokens.
>
>
> I was thinking about this. What if we just "hide" the "=", so that
> clang-format thinks there's just == or !=? I don't think we need to have any
> logic specific to javascript identity operators.
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>




More information about the cfe-commits mailing list