<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 12, 2014 at 12:10 AM, Mark Tullsen <span dir="ltr"><<a href="mailto:tullsen@galois.com" target="_blank">tullsen@galois.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We've been building a tool (eventually to be released BSD) for allowing<br>
programmers to write custom program properties (complexity, semantic,<br>
architectural, etc.) in a high level DSL (embedded in Haskell at the moment).<br>
We switched from a decent but ad hoc C99 parser to using the Clang front end and<br>
are very happy customers. We are using the libclang C interface via FFI.<br>
<br>
However, we lost one extremely useful capability in this transition. We had<br>
some really nice one-liners in our pre-clang days, e.g.,<br>
<br>
property1 = noUnreachableCode . removeDecls (hasPrefix "test_")<br>
<br>
// Remove all the declarations for test code from the project then<br>
// test to see if there is no unreachable code<br>
<br>
property2 = noUnreachableCode<br>
. removeDecls (hasPrefix "test_")<br>
. removeMembersFromStructs (hasPrefix "test_")<br>
<br>
// Ditto, but we also remove structure members that are only there<br>
// for testing purposes.<br>
<br>
If you don't grok Haskell:<br>
- The '.' above is function composition (like '|' in Unix)<br>
- removeDecls, removeMembersFromStructs, hasPrefix are higher order functions.<br>
<br>
With our switch to clang, we have lost the ability to do quick and easy<br>
wholesale project transformations like the above removeDecls function. We also<br>
have the need to do transformations that add to the code (e.g., inserting<br>
attributes). The output of these transformations (code slicing, mutations, extensions) may be<br>
only be for intermediate use and are not necessarily output for the sake of code refactoring.<br>
<br>
I'd really like to regain the ability to achieve such transformations. As we explore<br>
ways to do this, these are some of my thoughts:<br>
<br>
- These modules<br>
<br>
Refactoring.h - Framework for clang refactoring tools<br>
Rewriter.h - Code rewriting interface<br>
<br>
seem to be designed for applying changes to the source and cannot<br>
be readily used to modify the AST (nor the serialized form of the AST).<br>
<br>
Correct?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- One approach I'm considering is to write a custom encoder/decoder for the<br>
serialized AST for our Haskell code. I.e., porting the clang::serialization<br>
stuff to Haskell so that we can read and write .ast files.<br>
<br>
I saw some long past post to this list that discouraged this.<br>
But my question is not so much whether you think (as C++ coders) this is the *preferable* way,<br>
but<br>
<br>
IF someone is really keen for a 3rd party (non C++) tool to transform the AST<br>
<br>
- Is the above replace-serialization approach even feasible?<br></blockquote><div><br></div><div>I think it's feasible, but see below ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Any warnings/suggestions if we did try this?<br></blockquote><div><br></div><div>- the AST is huge and changes somewhat frequently (not so much in itself, but new AST nodes are introduced, etc); this might not be a big problem for you if you only care about C, but it might lead to non-trivial maintenance effort for the tool</div>
<div>- the AST invariants are hard to get right</div><div><br></div><div>In the end it's of course a cost-benefit trade-off. My best guess is that it's usually not worth to try to maintain an adapted out-of-tree serialization framework for clang's AST, but YMMV.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Are there alternative ways to do this that don't involve applying<br>
rewrites to the source and re-parsing?<br></blockquote><div><br></div><div>I'm not aware.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sorry for the long post. Any insights or guidance would be very helpful!<br>
<br>
- Mark Tullsen<br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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>
</blockquote></div><br></div></div>