[cfe-dev] Decls are not synonyms for the symbols they represent

[Ted Kremenek]

On Sep 17, 2008, at 12:19 PM, steve naroff wrote:

> I guess we could, however I'm still not sure it's the right thing to  
> do (since it goes against our tenet of keeping the AST simple and  
> reflective of the source). From the compiler's perspective, the 3  
> DeclRefExprs *should* bind to 3 different VarDecls.

I agree with Steve here.  The three separate declarations really are  
separate declarations that should be represented explicitly in the AST.

> For this example, I'd like to know why/when we care if all these  
> VarDecls refer to the same variable? Since each VarDecl is "extern",  
> it's the linkers job to bind the actual
> variable definition (which isn't in this particular translation unit).

This is somewhat of a bad example; it was mainly to illustrate a  
point.  However, there are cases for this example where clients do  
care that they refer to the same variable.  For example, the static  
analyzer, when analyzing these functions, may wish to know that these  
three declarations represent the same global variable.  Where that  
variable is actually instantiated is irrelevant; the linker just takes  
care of making sure their is storage slotted for that variable in some  
translation unit.  In other words,
we know that there is a global variable 'x' whose storage lies in some  
other translation unit; if the program were to link and run, it will  
be an actual variable in memory, so it doesn't really matter where it  
was defined.

> The "meta issue" here is how we preserve aspects of Sema's knowledge  
> without bloating/contorting the AST's. Like everything else we've  
> been doing with clang, it needs to be driven by actual clients. As  
> clang clients evolve, we need to consider API's that enable our  
> AST's to be used conveniently. Asking clients to re-implement  
> complex Sema merging/checking/etc. isn't practical. Note that  
> ImplicitCastExpr was added to make the code generators life more  
> convenient - without it, the code generator would have to be in the  
> type conversion business (which Chris/I wanted to avoid, given C's  
> arcane rules). So, changes to the AST's are certainly not out of the  
> question...we just need to be clear on the cost/benefit.

My thoughts exactly.  It would be great if some of this information  
could be stored in external data structures; clients who wish to keep  
that information could do so, and otherwise it could get  thrown away  
once Sema is done with it.