[cfe-dev] facebook clang plugins

[Sean Silva]

On Sat, Jun 21, 2014 at 3:52 AM, Manuel Klimek <klimek at google.com> wrote:

> 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).
>

I was talking about a possible simplification of the implementation, not
the API it exposes to users.


>
> 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.
>
>
The documentation that you guys have produced for the matchers is quite
good and could largely be reused/shared/migrated/adapted to the relevant
part of the AST itself. (As you said, it would be a lot of work though).


-- Sean Silva


>
>>
>> -- 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/ed7607dc/attachment.html>