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

[Argiris Kirtzidis]

Chris Lattner wrote:
>
> 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.

Come on, a refactoring engine that can't find all the references unless 
the code compiles ? The java guys will laugh at us :-)

>
> 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++ :).

Yeah, of course getting C++ out has the priority. It's just that I think 
the longer we put it off, the harder it will get in the future.

>
> 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.

Given that "find all references of this specific variable named 'foo' 
here, with the added bonus of working on code that doesn't compile" is 
the specific, non-theoretical problem, what better way is to solve it 
than the parse tree ?
Ok, maybe building a highly specific action module that responds on 
identifiers, etc.
How long before things break down under the weight of stuff like:

  NS::Cls<foo>::foo = 0;

Since Sema is "parse-tree-with-checks", it seems doable and reasonable 
to turn it into "parse-tree + checks".

Anyway, the "give me the AST without checks" doesn't seem to interest 
anyone else. At least the consensus is that Sema should definitely break 
apart.

-Argiris