[cfe-dev] Should we build semantically invalid nodes?

Chris Lattner clattner at apple.com
Mon Oct 27 13:15:44 PDT 2008


On Oct 27, 2008, at 12:55 AM, Argiris Kirtzidis wrote:
>> I strongly believe that trying to refactor code that doesn't work  
>> is a bad idea.  There are specific things that can be done by  
>> (e.g.) matching braces that can make sense on invalid code (for  
>> example, Xcode has a textual "rename in scope") but I don't  
>> consider those to really be refactoring.  If/when we have  
>> refactoring and this becomes a blocker, we should figure out what  
>> the right approach is then IMO.
>
> I totally see your point about a powerful refactoring engine that  
> has strong guarantees about what it does.

>
> I'm talking about a more practical (I mean, "weak" guarantees)  
> approach, on the style of "look, at the current state of code, I see  
> these locations here as references", then a list is displayed to the  
> programmer so he can check and approve/disprove each transformation.
> The ideal situation would be that the code compiles so that all  
> references are found, but this choice is left to the programmer.

That isn't "refactoring" by the common definition.  Refactoring is a  
behavior preserving change to the code.  If the code doesn't compile,  
it has no behavior.  While you could vacuously claim that preserving  
"lack of behavior" conforms to the common definition, I think that is  
stretching it.

What you're talking about is syntax directed editing.  There are many  
ways of doing this that don't require ASTs and have good results.   
Many intelligent editors sport these features.

> Here's another suggestion:
> Going the break-up-Sema way like:
>
>> To me, it would be ideal if we could split up Sema into different  
>> modules somehow based on purpose (types, decls, expr/stmts, c++,  
>> objc, etc) rather than split up each individual action callback.
>
> Is awesomely valuable since it will actually make it easy to build  
> custom/specialized action modules.
> How about an Action library that holds the components from where  
> Sema (and possible other modules) is built ?
> And another action module that will help identify and get the  
> components out of Sema for reuse ?

Sure, I don't really know how this would work out, but if it preserves  
the functionality and performance of Sema, I'm all for it.  I would  
love to see sema multiple related classes instead of one huge one  
(similar to how codegen is broken up).

-Chris



More information about the cfe-dev mailing list