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

[steve naroff]

On Sep 17, 2008, at 2:46 PM, Argiris Kirtzidis wrote:

> Ted Kremenek wrote:
>>
>> The problem that I'm concerned with right now is that there are  
>> cases where two DeclRefExprs can refer to different VarDecls that  
>> correspond to the same variable, but a client of the AST has no way  
>> of knowing that that is the case.  Consider:
>>
>> ----
>>
>> extern int x;
>>
>> void foo() {
>>  x++;
>> }
>>
>> extern int x;
>>
>> void bar() {
>>  x++;
>> }
>>
>> void baz() {
>>   extern int x;
>>   x++;
>> }
>>
>> -----
>>
>> If you do an AST dump of this, you will see that the DeclRefExprs  
>> for 'x' in foo(), bar(), and baz() respectively refer to separate  
>> VarDecls.  Right now a client of the ASTs has no way of knowing  
>> that these VarDecls refer to the same variable.  Certainly a higher- 
>> level API that resolves identifiers across translation units could  
>> do this, but it might have to do a lot of work to resolve  
>> situations like the one above.  By having a mechanism to resolve  
>> identifiers within a translation unit, this higher-level API would  
>> much easier to implement.
>
> An "IdResolver" used beyond Sema would be very useful, but it may  
> come with a memory cost.
> Could we get away with having all DeclRefExprs for 'x' refer to the  
> same VarDecl ?
>

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.

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

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.

snaroff