[PR c++/87531] Fix second bug
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4383 bytes
Desc: not available
More information about the Gcc-patches