Re: [rfa] teach lookup_symbol about namespace scope

[David Carlton <carlton@math.stanford.edu>]

On Fri, 16 May 2003 10:53:34 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> OK, here it goes. I have been ruminating on this patch a long time,
> and I have really mixed feelings about it, no that's not accurate, I
> am completely torn about it.

I'm not surprised to hear that, because I basically share your
qualms.

> On the other hand, the generic flow of control of the symbol search
> gets pulled into c++ territory.

Right.  So what do we do about that?  Some possibilities:

1) Have a separate lookup-symbol function for each language, and make
   sure it gets called wherever is appropriate.

2) Put language-specific hooks in the generic lookup_symbol function.

3) Have the knowledge about what to do actually embedded in the blocks
   themselves.

I don't think option 1 is all that great an idea: e.g. C and C++ share
a parser (and might eventually share it with Objective C as well), so
you don't know which lookup function to call, or in decode_variable
(within decode_line_1), you don't really know what the ambient
language is, so you really want a single function that works for all
languages.

Option 3 might well be a good idea in the long term, and probably my
dictionary patch will begin to set up the framework necessary for
that, but it's far too big a leap for me to want to consider that now:
I just want to get C++ working better.

So that leaves us with option 2.  And, actually, I think there's a
natural place to put a hook:

* Allow languages complete control as to what happens after the local
  variables are looked up.

Local variable lookup is, I hope, fairly uniform across languages.
But the 'is_a_field_of_this' check isn't relevant to C.  The new
namespace stuff isn't relevant to C.  And all of that happens after
local variables are looked up, either before or instead of
global/static symbol lookup.  So that seems to me to be the right
place to allow languages to seize control; if we need more hooks
later, we can add them, but that will give us some place to start, and
will allow me to move my namespace lookup algorithm to cp-support.c or
cp-namespace.c.  I assume this would work for whatever needs
Objective-C has; I'll add Adam to the Cc: list in case he wants to
chime in.  (We should really add him to the MAINTAINERS list as
Objective-C maintainer one of these days.)

To get this to work, we'll obviously need to provide a way to locate
the language associated to a given block.  My first instinct was to
add a 'language' member to each block, but poking around, the symtab
already has that information: how about just adding a 'symtab' member
to each block?  (Or even just to global blocks, if that is any easier
to write: we can bury the details of its access in a function
'block_symtab'.)  That would help make sure that the information is
consistent, and would let us get rid of the ALL_SYMTABS bit in
lookup_symbol_aux_block.

If this sounds good, I'll get to work on it; it should be easy enough
to do, I think.  I have a pretty good idea of what functions symtab.c
will want to export to make life easier for other languages.

> Anyway, here is the symtab.c portion of the patch updated to reflect
> the namespace-->domain changes.

Thanks.

> (about the test changes: do you use namespace1.cc at all? I don't see
> you hooking that up to anything).

Oh, whoops, sorry about that.  Good thing Daniel was asking me to
include tests for symbols in namespace1.cc that are actually supposed
to find a variable instead of not do so...

David Carlton
carlton@math.stanford.edu