[cfe-dev] Clarification for term "AST"

[Joshua Cranmer]

On 2/24/2013 5:38 AM, Markus Elfring wrote:
>
>> I can't say that I can think of a single time where I would ever want 
>> the raw parsed AST with no semantic analysis done on it.
>
> Are you interested in detailed source code transformations after a 
> specific analysis on a control flow graph?
> Do you see use cases to drill down from higher abstraction levels to 
> the abstract syntax tree to generate some adjustments?

The short answer here is "no", because viewing refactorings as 
transformations on ASTs is wrong. Refactoring is really transforming 
source text to source text guided by high-level semantic rules; treating 
it as AST implementations will cause lots of grief when you try to 
reserialize that AST, thanks in large part to the complications of 
macros and templates (macros++).

> How do you think about consequences and challenges like they are 
> demonstrated by the semantic patch language from the software 
> "Coccinelle"?
> http://coccinelle.lip6.fr/sp.php

Semantic patching is very seductive, but it's a poor substitute when it 
comes to complicated refactorings. The use case I played with a few 
years ago was rewriting a C API into C++, which requires some semantic 
rules cumbersome to produce in an spatch-like format. The best example I 
have is "make the first argument to be 'derived' from MimeObject be the 
implicit this argument." Another one is "every object which is the 
implicit this argument cast to some other type is really just the 
implicit this argument, if the cast is a cast to the current class type 
or some superclass thereof".

-- 
Joshua Cranmer
News submodule owner
DXR coauthor