Re: C++ PATCH to cp_parser_postfix_expression

[Nathan Sidwell <nathan at codesourcery dot com>]

Jason Merrill wrote:
> We were failing to set idk to CP_PARSER_ID_KIND_QUALIFIED for the case of a
> name qualified with both object and scope.  As a result, we were
> incorrectly doing virtual lookup for some function calls.
>
> Fixes g++.dg/overload/virtual1.C, a regression from 3.3.
>
> Tested i686-pc-linux-gnu.  Mark, does this look like the right fix?
>
> 2003-02-12  Jason Merrill  <jason@redhat.com>
>
> 	* parser.c (cp_parser_postfix_expression): Set idk properly for
> 	object->scope::member.
This is PR 9485. I looked at that, and whilst a patch like yours fixes the
bug, it occurred to me that something along the lines of getting
cp_parser_postfix_expression to return an idk value might be better. I wrote
something about it to Mark:
--snip
PR 9485 turns out to be a new parser bug. I've had a look, and am in
two minds about how to fix it. The basic problem is that
in
     ptr->A::fn ()
we forget that A::fn was a qualified name, and therefore do a LOOKUP_NORMAL
rather than LOOKUP_NONVIRTUAL in build_new_method call.

The CPP_DEREF case in cp_parser_postfix_expression is the culprit here.
It doesn't set idk at all. Now, setting idk changes its meaning slightly
because the postfix expression isn't an identifier, but I think that's
livable with. idk is currently set by cp_parser_primary_expression and not
by cp_parser_id_expression.

My thoughts are to have cp_parser_id_expression set a *idk parameter,
therefore removing code from cp_parser_primary_expression. I think the
template_p pointer arg of cp_parser_id_expression can go away too, and
you'd have to expand the CP_PARSER_ID_KIND enumaration to a set of
bit-masks.
-- end

I suspect that got lost.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
         The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org