Re: [rfc] struct dictionary

[David Carlton <carlton at math dot stanford dot edu>]

On Tue, 29 Apr 2003 16:06:02 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> I kind of get the impression that I'm missing your point somehow
>> and that we're talking past each other.  I'll post a concrete patch
>> soon (Wednesday, maybe?  It's done on my laptop, but I don't have
>> my laptop with me), and hopefully that will clarify matters.

> Sounds like it.  I'm think I'm looking a step beyond your changes.

Good, because I think/hope so too.

> Is the block's symbol search algorithm determined by the language?

Sort of yes, sort of no.  lookup_block_symbol itself doesn't depend on
the language: it has one subtlety that depends, basically, on whether
or not the block is associated to a function, but that doesn't have
anything to do with the language.

But that's just lookup_block_symbol.  lookup_symbol itself implements
C/C++ name lookup, so if languages are too different from C or C++,
they might have to implement their own custom lookup rules.  And,
unfortunately, my current namespace patch that's awaiting review
increases the amount of C++-specific cruft in there.  It does it in
such a way that the C execution path shouldn't get slowed down, but
I'm still not happy with its presence at all: currently, GDB is too
C-centric, but changing that to being C++-centric isn't exactly an
improvement.  (For what it's worth, until my first namespace patch,
struct block didn't have a language_specific member at all.)

There shouldn't be anything in any of these functions that depends on
the language of the symbols themselves.  There's some code in various
functions to treat Java symbols differently when searching, but that
code really shouldn't be there.

I have some ideas about representing things like using directives,
anonymous namespaces, namespace scope, and for that matter the simple
case of looking up a C global variable in terms of dictionaries.  I
want to get things working first in a way that is, I think, not too
hard to understand, but I hope there will be time to reflect on the
situation later and change the implementations to move more of the
C++-specific code to a more appropriate location.

One issue that we'll have to grapple with is that the
language-specific rules aren't really localized to a single block.
For example, name lookup looks something like this:

1) Look in local variables.

2) Look to see if we're referring to a member of the current class.

3) Look in global and static variables.

Now, step #2 isn't relevant to C, and for that matter I would imagine
that different object-oriented language might have some subtle
differences in the exact semantics of step #2.  So it's a good
candidate for a language-specific hook: but where should the hook go?
We don't want to do this all the time, after all: only if we're
executing a member function.  And currently that information doesn't
really fit into our blocks at all.

I can imagine possible solutions.  One is to move BLOCK_SUPERBLOCK
inside of dictionaries, and then allow dictionaries to implement their
own strategies for what do do next (basically, to let them implement
lookup_symbol instead of just lookup_block_symbol).  Another
possibility would be to, when creating the block associated to a
method, have its superblock not be the current file's static block but
instead be a dummy block that exists only to provide a dictionary to
lookup a member of the current class.  (Of course, this also raises
the problem that members aren't represented by symbols: so what do we
do about that?)  I'm sure that there are other possibilities as well;
I'm not sure which of them is best.  And I also don't know exactly
what effects this will have on the symbol readers.

David Carlton
carlton@math.stanford.edu