public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Olivier Galibert <Olivier.Galibert@mines.u-nancy.fr>
To: egcs@cygnus.com
Subject: Re: namespaces -- time to do something?
Date: Tue, 09 Dec 1997 19:34:00 -0000	[thread overview]
Message-ID: <19971210043419.02748@loria.fr> (raw)
In-Reply-To: <u9n2i9534e.fsf@yorick.cygnus.com>

On Tue, Dec 09, 1997 at 06:44:01PM -0800, Jason Merrill wrote:
> I've already sent out my design for a rewrite of the lookup code, which is
> already ill-suited to C++.  I'll see about digging it up again.

Per Jason's request, here comes his post again.

  OG.

To: egcs@cygnus.com
From: Jason Merrill <jason@yorick.cygnus.com>
Newsgroups: cygnus.egcs
Subject: Re: Test run and a question

>>>>> "Lassi A Tuura" <Lassi.Tuura@cern.ch> writes:

> Mike Stump wrote:
>> > when support for namespaces
>> 
>> The standard answer is when you add support and get it in, then it
>> will be in.  :-)

> Talking as one who knows *very* little about gcc internals... How big an
> effort are we talking about here?

Significant.

> I would presume the template/namespace twistedness (Koenig rules) is the
> most difficult part...

Nah, that shouldn't be hard once the basic support is there.  Koenig lookup
just means you look up a function in multiple namespaces.  Maybe 10 more
lines of code.  The tricky bit is getting using directives right; the draft
says that a namespace nominated by a using directive is not searched in the
scope where the using directive appears, but rather in the lowest common
denominator of that namespace scope and the current scope.  The
time-consuming bit is going through and fixing all the uses of the current
name lookup stuff.  Here's a design document I put together for later use
in reimplementing scoping.  Anyone is welcome to work on it, or just
comment; I won't be able to work on it for quite a while.

Jason

-------
A more detailed design.  Feedback welcome.

Two "value fields" per id:  unqualified and qualified.  Both are lists.

The unqualified field is a stack of decls for the identifier, in order of
precedence.  Each entry has a level number.  Lookup that just finds types
or labels can scan the stack until it finds something of the proper
variety. Decls check for duplicates in the current level.  At the end of a
block, we walk the block's list of names and pop all the decls in the
current level for each name.  For methods, we set up a single binding level
for the class and its bases.  When defining a class, we set up a binding
level for the bases (using the same code), and another for the class
itself.  Lookup that ignores class scope can step over decls from class
scope (by checking a flag on the stack entry).

For push_to_toplevel we walk down the binding levels, storing the value of
the unqual field for each name used in any of the binding levels, and
skipping the decls lower than namespace scope.  In pop_from_toplevel we
just restore the saved values.

The qualified field is a self-modifying list of namespaces and
corresponding decls.  Perhaps the value field of each node should be a list
to allow for type and non-type values, or perhaps they should just be two
entries in the main list.

We also maintain a stack of used namespaces, along with the level number of
the using directive and the level number of the namespace in question.  If
unqualified lookup passes the level number of one of these namespaces, we
look up the name there before continuing up the unqual stack.  Each
namespace has a list of using-directives, and the nominated namespaces are
also checked.

Perhaps the used namespaces should also be noted in the binding level, so
we can look up a name in two steps: First, look at the first decl hanging
off the identifier.  Then walk the binding levels up to the level of that
decl to find any used namespaces.  If we only kept the stack, we would have
to walk the entire stack for each binding level.

Perhaps failed namespace-level lookups should be cached by adding a
NULL_TREE value for the namespace in question so we don't scan the whole
list of qualified bindings for a name each time we look it up.





  reply	other threads:[~1997-12-09 19:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <199712091617.KAA27851.cygnus.egcs@fsui02.fnal.gov>
1997-12-09 18:44 ` Jason Merrill
1997-12-09 19:34   ` Olivier Galibert [this message]
1997-12-10 19:28     ` Per Bothner
     [not found]     ` <199712110309.TAA00961.cygnus.egcs@cygnus.com>
1997-12-10 19:56       ` Jason Merrill
1997-12-09  8:17 Marc W. Mengel
1997-12-09  8:25 ` Jeffrey A Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19971210043419.02748@loria.fr \
    --to=olivier.galibert@mines.u-nancy.fr \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).