<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 3:52 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Sat, Jun 21, 2014 at 2:33 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. <div>
<br></div><div>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.</div>
<div>
<br></div><div>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.</div>
<div><br></div><div>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 ;)</div><div><br></div><div>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 <a href="http://llvm.org/bugs/show_bug.cgi?id=20061" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=20061</a>).</div>
</div></blockquote><div><br></div></div><div>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).</div>
</div></div></div></blockquote><div><br></div><div>I was talking about a possible simplification of the implementation, not the API it exposes to users.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>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.<br>
<br></div></div></div></div></blockquote><div><br>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).<br>
</div><div><br></div><div><br>-- Sean Silva<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><font color="#888888">
<div><div><br></div><div>-- Sean Silva</div></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 10:30 AM, Mathieu Baudet <span dir="ltr"><<a href="mailto:mathieubaudet@fb.com" target="_blank">mathieubaudet@fb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I am looking for feedback on the possibility of contributing some of the clang plugins used at Facebook back to clang.<br>
<br>
We just made available a first subset of plugins here: <a href="https://github.com/facebook/facebook-clang-plugins" target="_blank">https://github.com/facebook/facebook-clang-plugins</a><br>
<br>
The plugins fall into two groups:<br>
1) Clang analyzer checkers for iOS;<br>
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.<br>
<br>
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.<br>
<br>
Thanks!<br>
—<br>
<span><font color="#888888">Mathieu Baudet<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>