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

[Nico Weber]

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
<arthur.j.odwyer at gmail.com>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 <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
> >
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131121/b7e160d4/attachment.html>