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

[Chris Lattner]

On Oct 26, 2008, at 2:17 PM, Argiris Kirtzidis wrote:
>> Good IDEs would use simple syntactic information about (e.g.)  
>> namespaces etc.  While it's true that you have to do full AST  
>> building to handle the fully general cases, the tradeoff is that  
>> you can't keep the index up to date as fast and it requires a bunch  
>> more memory.  Because of this, most IDE's use a fuzzy parse that  
>> does not do AST building or type checking to get this info.
>
> In this futuristic, multiple-processor, lots-a-GB, world, I don't  
> think we can't afford to just get all the references of a variable.  
> What you describe is chronically awful tool support for C++ because  
> of its complexity (compared e.g. to java); we can certainly improve  
> things here, right ?

I don't claim to know, but I hope so :).  This is one of those things  
that probably needs to be backed by experimentation and hard numbers,  
not speculation.

>> On Oct 26, 2008, at 12:57 PM, Argiris Kirtzidis wrote:
>>> Anyway, if the consensus is that the parse tree is not important,  
>>> I'll
>>> shut up :-)
>>
>> To be perfectly clear, I think this was a really interesting and  
>> useful discussion.  The only reason I'm pushing back so hard is  
>> that we already have lots of concrete problems to solve.  I think  
>> we should only pursue this sort of thing in the future, if/when the  
>> lack of this capability is blocking something.
>
> I'm not sure I understand whether I'm "barking at the wrong tree" or  
> not. My point is that the parse tree is important for IDEs in  
> general and refactoring in specific; not having it is  
> "blocking" (well limiting more accurately) this kind of uses ("find  
> me all references of 'foo'").

I agree that there are theoretical cases where this can be useful.   
However, if I were working on a refactoring implementation (hopefully  
someday, but not until more basic stuff is working!), it would come  
down to priorities.  As I said before, this is an engineering  
tradeoff.  For example, if we don't "solve this problem" today, it  
will boil down someday to having a choice between investing effort in  
a) refactoring invalid code, or b) investing the same effort into  
adding new features, polishing the user experience, etc.  Unless the  
refactoring engine were maximally mature already, I'd almost always  
(and this is just my personal preference) put that energy into B.

If you want to solve this problem today, it seems to me that we're  
putting energy into solving a much lower priority problem than getting  
basic refactoring to work, or solving one of the other problems that  
are still open (e.g. C++ :).

I don't see how it is worthwhile to worry about right now, and it's  
not clear to me that it would ever bubble up to be a high enough  
priority to solve.  One of the good things about designing things  
lazily is that it means you design the solution when you are feeling  
the pain.  This means you have a lot of context to design a solution.   
Designing a solution for a (currently) theoretical problem runs the  
risk that we'll either a) solve the wrong problem, b) solve the right  
problem with a suboptimal approach, c) be obsoleted by some other  
factor before the solution gets used.

> It's one thing to say that "the parse tree is important for this  
> stuff and we'll get to it in the future", and another that "I don't  
> think having the parse tree makes a difference to anything, but if  
> we find some use for it in the future we'll consider it".
> So which exactly is it ?

For me, the later.

-Chris