Hi Arthur, 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."
Nico On Thu, Nov 21, 2013 at 4:53 AM, Arthur O'Dwyer <[email protected]>wrote: > 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 <[email protected]> > wrote: > > On Wed, Nov 20, 2013 at 4:03 PM, Daniel Jasper <[email protected]> > 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 > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
