[PR c++/87531] Fix second bug

Nathan Sidwell nathan@acm.org
Thu Dec 13 14:11:00 GMT 2018

This patch addresses the regression caused by the first fix.  For 
reasons that used to make more sense, an overload set of template 
members would present as just a dependent using-decl, if it contained 
any such using decls.  Then we'd defer repeat lookup to instantiation 
time.  Except in a couple of places where we'd really want the 
non-dependent function set.

However, we're now better at doing lookups correctly in more places, and 
this deferring gets in the way.  In this particular case, we need to know if
    name < whatever >
is a template-id-expr, or a less-than operator[*], and we determine this 
by seeing if any members of whatever 'name' found are templates.  This 
breaks if we just present a dependent using decl.

So, this patch removes the frobbing in name lookup and returns the whole 
binding.  We'll have arranged that if there is at least one dependent 
using decl, it'll be first in the overload set.

Then we need to deal with that as an overload member in a couple of 
places.  The finish_id_expr change is so we properly insert an implicit 
'this->' before hand.  That showed I'd neglected to set the using-decl's 
DECL_CONTEXT, hence the change in finish_struct.

get_class_binding_direct's fn_or_type arg can now return to be a bool 
'want_type', as we no longer call it with the 'want_fns's' value. 
That's a cleanup for stage 1. (The only other place we asked for fns is 
getting the dtor, which cannot be a dependent using decl anyway, so the 
request is moot.)

Booted & tested in x86_64-linux, applying to trunk and gcc-8.


[*] there's a core or evolution paper about interpreting '<' as a 
template-id-expr in more places regardless of the binding of the single 
identifer on its left.

Nathan Sidwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr87531-2.diff
Type: text/x-patch
Size: 4383 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20181213/27e21619/attachment.bin>

More information about the Gcc-patches mailing list