Re: RFD - cleaning up C identifier lookup

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Firstly, I would like to state from the outset that I'm pursueing two
goals:

   1) reduce name-lookup time on both 3_3-branch and mainline 
   2) devise a minimal patch that can make it into 3.3.0.

I assume that you're mostly speaking of the long-term solution
(i.e. for mainline).

Zack Weinberg <zack at codesourcery dot com> writes:

| Gabriel Dos Reis <gdr at integrable-solutions dot net> writes:
| 
| > Zack Weinberg <zack at codesourcery dot com> writes:
| ...
| > | struct lang_identifier GTY(())
| > | {
| > |   struct c_common_identifier common_id;
| > |   tree symbol_value;
| > |   tree tag_value;
| > |   tree label_value;
| > | }
| ...
| > | Much of this stuff could also be applied to the C++ front end also,
| >
| > That might; but in fact, that would be a complication (and hardly an
| > improvement over current situation) for C++. 
| >
| > A distinction is that C++ has a single name space  as opposed to C.
| > An immediate consequence is that the C++ front-end would have to jump
| > through whoops to ensure that we can C++ semantics right.
| 
| By this you mean that symbols and tags occupy the same namespace,
| right?

I was too imprecise: I meant variable-name, function-name, class-name,
namespace-name, enum-name, type-name, template-name are in the same
name space. 
(In C, tag-name and variable name are kept in distintc name spaces).
However, the 'struct stat' hack is still permitted in C++.

The C fron-end has a notion of "tag-transparent" binding level
(carried over to the C++ front-end).
I'm trying to get rid of it in the C++ front-end -- the notion of
scope that may have a meaning of tag-transparent binding level is the
notion of template prototype scope.

|  6.1p1 [stmt.label] says that labels have their own namespace,
| so I think you'd still need the pointer for that.  (However, labels

Right.

| are rare enouugh that it might be worthwhile to use a separate table
| for them, saving more space in the identifier.)
| 
| 
| > The route I take on this issue for C++ is to get rid of the confusion
| > notions of binding-level and scope in G++.  Instead, I just use the
| > standard notion of scope and implement essentially 
| >
| >   1) local scopes (these are blocks) with the refinements:
| >        + try-scope
| >        + catch-scope
| >        + for-while scope
| >   2) function prototype scopes
| >   3) class scope
| >   4) namespace scope
| >   5) template prototype scope
| 
| C99 has for-while scope and function-prototype scope, too.  And
| there's also file scope.

The C notion of file scope, roughlty speaking, corresponds to C++'s
notion of  global scope -- which is just an instance of namescope-scope.  

| I'd like to do something compatible with merging the C and C++ front
| ends in the future, and I can see getting rid of the binding-level
| concept as worthwhile for C too (but I want to do this incrementally).

Understood.  But, I'm already in the middle of binding-level/scope
unification.  

| I don't think the conflicts here are severe.  What would you suggest I
| do to bring things into congruence?

While some data structures might be shared, I believe C and C++ name
lookup rules are really distincts so I don't know how much of the
algorithms might be shared *if* we keep the current "all state
variables are implicit and you've got to play games with holy stacks"
approach.  I believe that a first step would be to have all those name
lookup routines take an explicit scope argument -- in that way sharing
algorithms might be less painful.

I believe we can just use a hash-table to implement name bindings,
instead of TRRE_LISTs are currently done.  I shoudl be able to report
numbers for the minimal patch for 3.3 today.

-- Gaby