public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Sami Wagiaalla <swagiaal@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Project Archer <archer@sourceware.org>
Subject: Re: [RFC] Koenig lookup patch
Date: Tue, 17 Mar 2009 18:39:00 -0000	[thread overview]
Message-ID: <49BFEE44.7080901@redhat.com> (raw)
In-Reply-To: <m3d4clrs4z.fsf@fleche.redhat.com>


> Sami>  space_identifier : '@' NAME
> Sami> +		|  '@' UNKNOWN_NAME
> Sami>  		{ push_type_address_space (copy_name ($2.stoken));
> Sami>  		  push_type (tp_space_identifier);
> 
> You have to duplicate the actions here.
> 

Hmm it looks like NAME is no longer nessesary here

> Sami> +    if (sym == NULL && !lookup_minimal_symbol (tmp, NULL, NULL) && !is_a_field_of_this)
> 
> lookup_minimal_symbol definitely won't follow the normal C++ lookup rules.
> So, this is not really implementing the C++ spec.
> 
> I am not sure this can really be done in the lexer.
> 
> I suppose you could look for a class member, based on the parser
> context, and return NAME in that case.  I don't know whether that
> would always be correct.
> 
> Another possible approach would be to have a C-specific evaluate
> function (other languages have examples of this, and the charset
> branch does it for C) that changes the function call code to do
> C++-specific stuff.
> 

This is done to distinguish an adl_func from names which are meant to be 
  found through lookup_minimal_symbol. Without this check tests for 
checkpoint try to call 'lseek', this gets wrongly reduced to an 
adl_function and the later ADL lookup fails.

> Sami> +  static char** prefix_array = NULL;
> Sami> +  static int    prefix_array_size = 0;
> 
> Statics are usually bad.  I guess this is to avoid adding extra
> arguments all up and down the evaluate_* call chain...
> 
> Another approach would be to factor some of the code out into a helper
> function, then call it.  Then things like that can simply be
> arguments.
> 
> If you want to stick with the statics, you will have to add cleanups,
> as right now they can be leaked.  Also I think you will have to change
> how they are allocated, because the value can be overwritten by a
> recursive call to evaluate_subexp_standard.
> 
> Sami> +                sym = lookup_symbol(concatenated_name,
> Sami> +                    exp->elts[pc + 1].block, VAR_DOMAIN, (int *) NULL);
> Sami> +
> Sami> +                if (sym)
> Sami> +                  {
> Sami> +                    exp->elts[pc + 2].symbol = sym;
> Sami> +                    break;
> Sami> +                  }
> Sami> +              }
> 
> I suspect this kind of thing belongs elsewhere.
> 
> My understanding is that ADL can add some symbols to the overload set.
> But, this seems to stop when it finds any matching symbol.
> 
> Instead I would expect to find this in the code that computes the
> overload set.  I see later there is a call to find_overload_match, but
> given that I don't understand the need to do a lookup_symbol here.
> 

Yeah, the above code can actually be moved into find_overload_match I 
never really thought of it that way. This will get rid of the statics, 
and allocation problems.

> Rewriting the expression in-place seems a bit weird.

It makes sense to me. You see the parameters of this expression actually 
depend on the result of the evaluation of the parameters particularly of 
the parameters are expressed in complex expressions and not plain 
variable names.

> It may always work, but I am not certain ... I'm not sure whether a
> parsed expression can validly be re-evaluated in a context other than
> the one in which it was created.
> 

If by context you mean scope, that is preserved and passed in as part of 
the "pre-expression" here exp->elts[pc + 1].block. I cant think of 
anything else but we can adapt this when we run into such cases.
> 
> One thing I would like to see is a reasonably comprehensive set of
> tests, in particular including tests of whatever odd cases there are,
> and of some error cases.

Looks like I forgot to git add my tests. Please see:
  git show fbf9dc5c8c817b100ad7ce5c680c4bf346e326df

Thanks for the review. I'll post an update version soon.

Sami

> 
> Tom

  reply	other threads:[~2009-03-17 18:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13 19:58 Sami Wagiaalla
2009-03-13 22:10 ` Tom Tromey
2009-03-17 18:39   ` Sami Wagiaalla [this message]
2009-03-17 21:25     ` Tom Tromey
2009-04-29 15:51   ` [RFC] Koenig lookup patch 2 Sami Wagiaalla
2009-04-30  0:19     ` Tom Tromey
2009-08-27 14:35       ` Sami Wagiaalla
2009-08-27 21:49         ` Tom Tromey
2009-10-14 20:29           ` [RFC] Koenig lookup patch 3 Sami Wagiaalla
2009-10-14 21:01             ` Sami Wagiaalla
2009-10-15 20:48               ` Tom Tromey
2009-11-02 19:11                 ` Sami Wagiaalla
2009-11-09 19:29                   ` Tom Tromey
2009-11-17 16:04                     ` Sami Wagiaalla
2009-11-17 20:51                       ` Tom Tromey

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=49BFEE44.7080901@redhat.com \
    --to=swagiaal@redhat.com \
    --cc=archer@sourceware.org \
    --cc=tromey@redhat.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).