[cfe-dev] facebook clang plugins

[Manuel Klimek]

On Sat, Jun 21, 2014 at 2:33 AM, Sean Silva <chisophugis at gmail.com> wrote:

> I'd just like to say that even if OCaml tools parsing JSON is out of scope
> as Nico suggests, the work you have done to "schematize" the Clang AST
> could be the start of something really useful for upstream. Currently, I
> can think of at least two places that would benefit greatly from having
> such a schema as a "single point of truth": Serialization and ASTMatchers.
>
> Being able to auto-generate those two from a schema (maybe in the form of
> annotations in the header files) plus a relatively small amount of
> generator code could eliminate thousands of lines of code.
>
> If RecursiveASTVisitor (~2500 lines) and TreeTransform (~10k lines) could
> also be generated from the "single point of truth" with relatively little
> code, then that would be a tremendous savings.
>
> I think your OCaml tool would be quite easy to write with Clang annotated
> as such, but you could let the Clang developers maintain the annotations
> for you ;)
>
> This might also pave the way for a more "data-driven" approach to the
> DynamicASTMatchers, which could significantly reduce the binary size (which
> is enormous, and IIRC is mostly due to the fact that is just
> pre-instantiates all the static templates). The same approach might work
> for the "static" ASTMatchers too, letting the compiler essentially
> constant-fold all the indirections (which will largely be member pointers I
> imagine). This might also improve compile time (which is an issue; see
> http://llvm.org/bugs/show_bug.cgi?id=20061).
>

Generating code for the AST matchers is something we would like, but I
think it's orthogonal to the general design of the matchers (we still want
the functional composition), so I'm not sure how it would help with the
things you mention (apart from getting rid of the manually written
matchers, which would still be a big win).

One of the big problems would be how we auto-generate the documentation for
the AST matchers, though. I agree that it would be better to have the
documentation (and the examples) on the nodes, but that'd be a lot of work.


>
> -- Sean Silva
>
>
> On Thu, Jun 19, 2014 at 10:30 AM, Mathieu Baudet <mathieubaudet at fb.com>
> wrote:
>
>> Hi,
>>
>> I am looking for feedback on the possibility of contributing some of the
>> clang plugins used at Facebook back to clang.
>>
>> We just made available a first subset of plugins here:
>> https://github.com/facebook/facebook-clang-plugins
>>
>> The plugins fall into two groups:
>> 1) Clang analyzer checkers for iOS;
>> 2) A clang frontend plugin to export the internal AST of clang in an
>> Ocaml-friendly Json. This plugin comes with Ocaml libraries for testing,
>> parsing, and visiting the AST.
>>
>> Except for the naming conventions, which are not uniform yet, and the
>> need to update the referenced version of clang, the code should be in a
>> relatively good state. In particular, everything has been tested quite at
>> scale.
>>
>> Thanks!
>> —
>> Mathieu Baudet
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140621/294f6b17/attachment.html>