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

[Ted Kremenek]

On Oct 26, 2008, at 12:57 PM, Argiris Kirtzidis wrote:

> The specific issue is that you cannot get a parse tree out of Clang.
> I don't think I convinced anyone about the importance of the parse  
> tree for IDEs but please note that refactoring in Visual Studio and  
> Eclipse works on semantically invalid code.

Understood.  My point was that until someone writes a similar  
refactoring client for clang it's requirements will remain mostly  
hypothetical.  I think there are multiple possible solutions for a  
refactoring client that wishes to operate on partially incorrect code,  
some which could involve Sema and others that do not.

> My concern is that Sema will just get bigger and the parse tree will  
> never be provided (or it will be a bitrotting piece of code) since  
> compiling/static analysis will be the focus.

I understand your concern, and my only answer is that things that need  
to get implemented will.  If there is a solid need for the parse tree,  
be it an IDE or a refactoring client, then support for parse trees  
will get in there.  Once there is an actual client, bit-rot will be  
less of an issue because a real client will depend on that feature.   
Engineering a feature into Clang right now that no client uses will  
almost certainly result in bit-rot.

That said, I do understand the point of engineering for the future,  
but I prefer that we approach the issue by having a flexible design  
that we aren't afraid to alter or steer into a new direction, not by  
implementing a feature that will not be immediately used.

> The response for requests about a parse tree will be "build an  
> action module" or "use clang only on correct code", in the end  
> limiting the suitability of Clang for IDEs and/or limiting the parse  
> AST.

I don't think anyone is trivializing the potential value of parse  
trees, nor the effort that may be required to extract them.  Any push  
back on this issue comes from the fact that (a) there are no clients  
currently demanding parse trees and (b) we have plenty of other  
concrete problems to solve right now.