[cfe-dev] [cfe-commits] r50538 - /cfe/trunk/lib/Sema/SemaDecl.cpp

[Neil Booth]

Chris Lattner wrote:-

> On May 1, 2008, at 3:19 PM, Neil Booth wrote:
>
>> Does this give them local or global scope?  They should only have local
>> scope; it sounds like you're making them global.
>
> 'context' is related but different than 'scope'.  I think Argiris' fix is 
> the right one for this, but we still have the scope issue.
>
> What do you suggest here Neil?  Right now we walk up the scope chain and 
> insert the implicit definition at global scope, which prevents it from 
> getting popped off the scope chain.  Is it best to mark it somehow as being 
> locally defined or something, or is it best to remove it from the global 
> scope chain when popped?

I honestly don't know what's best; this is a messy area as the
ongoing other thread makes clear.  What I did, which was OK for C
but I'm not so sure about C++, is separate decls from what they
declare.  So I had a function entry in the IR, say, of which only
one exists for any given function declaration; it has the composite
type.  Each declaration gets a decl at the correct scope which
points to the function, but also has its own type override according
to what the type was when that decl was complete.

This means you can always see the correct type of any particular decl,
and obtaining the full composite type is also easy.  But the type override is a
pain.  And in C++ the problem is harder because it's not just type - default
args are not part of the type I believe?

The way I did my symbol table meant that finding a decl even when not in
scope wasn't a problem, so they were looked up and diagnosed regardless
of visibility.

I don't think there is an ideal solution to this issue; I wish the
language standards didn't permit block-scope declarations of things with
external linkage.  But in C++ you have the default args issue so it
still wouldn't be solved there.

> Alternatively, perhaps it shouldn't be added to global scope.  This would 
> make diagnosing the undefined cases harder, but they could be handled with 
> other hacks.

Right.  If you do it at global scope it should be fine, but needs to be
not visible to language name lookup when it goes out of scope.

Neil.