On Thu, Nov 21, 2013 at 7:01 AM, Alexander Kornienko <[email protected]>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 <[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? >> > > 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 > [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
