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

[Sean Silva]

On Thu, Nov 21, 2013 at 7:01 AM, Alexander Kornienko <alexfh at google.com>wrote:

> Nico has answered the main question in your e-mail, and if you're
> interested in the topic, I encourage you to find and read the thread, he
> quoted.
>
> I'd also like to comment on some specific points in your e-mail.
>
> On Wed, Nov 20, 2013 at 8:53 PM, 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?
>>
>
> Clang-format doesn't use libclang, which is a C interface to Clang.
> Clang-format also doesn't use Clang's parser. The only thing we use, is
> Clang's lexer, and all the parsing (quite relaxed, so it can be used on
> almost anything resembling valid C/++/ObjectiveC/++ code) is done by
> clang-format itself. So in order for clang-format to format a language,
> there's no need for Clang's parser to understand it.
>
> This patch implements formatting of some JavaScript constructs, not Java
> (though, we have plans to support Java). We'll probably need to change
> Clang's lexer to support some of the JavaScript syntax features (e.g.
> regular expression literals), but only if this is easier to do in the
> lexer, and if it doesn't affect its performance.
>

It will honestly probably be easiest to skip tokens until you reach the
matching `/` (taking into account nesting of `[a-z]` character classes and
such). Except for the pathological cases I discussed in the other thread
(which are truly pathological, and have trivial workarounds, and can likely
be detected by clang-format and diagnosed), this should always work.
Especially since all clang-format is doing is rearranging whitespace, as
long as you don't touch any whitespace in the interior of the regex
literal, it should be preserved.

-- Sean Silva


>
>
>> 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?
>>
>
> Keywords are usually not a problem, as they can frequently be treated as
> identifiers. Clang-format has a very relaxed parser, so it doesn't need to
> understand much of the language it formats.
>
> As for the operators not present in C++, this is what we can (and we'll
> have to) add support for on the side of clang-format, without touching the
> lexer.
>
>
>> Who's using clang-format on Java code, and why?
>>
>
> I don't think someone uses clang-format for Java and JavaScript code
> extensively, as we don't support these languages yet. But we have requests
> to support them from people, who are not satisfied with other existing
> formatters.
>
>
>>
>> –Arthur
>>
>> [* – By which I mean "saner than C++11's syntax", of course. :) ]
>>
>>
> --
> Regards,
> Alexander
>
> _______________________________________________
> 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/dbb313d4/attachment.html>