[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2022-05-12 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|9.5 |11.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jason Merrill  ---
The patch for this ended up causing a lot of problems, so I reverted it on the
10 branch and am not going to try to fix it in 9/10.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2022-04-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4195fced8a13422db94e179404588d9d887a036a

commit r12-8098-g4195fced8a13422db94e179404588d9d887a036a
Author: Jason Merrill 
Date:   Mon Apr 11 17:51:43 2022 -0400

c++: using operator= [PR105223]

In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet.  In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
type doesn't prevent the implicit declaration.

When I was working on that patch, the change was necessary to avoid another
regression, but apparently it is no longer needed.

PR c++/105223
PR c++/92918

gcc/cp/ChangeLog:

* class.cc (finish_struct): Always using op=.

gcc/testsuite/ChangeLog:

* g++.dg/template/using31.C: New test.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2022-03-18 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:47da5198766256be658b4c321cecfd6039b0b91b

commit r12-7714-g47da5198766256be658b4c321cecfd6039b0b91b
Author: Jason Merrill 
Date:   Fri Feb 25 15:07:15 2022 -0400

c++: using lookup within class defn [PR104476]

The problem in both PR92918 and PR104476 is overloading of base member
functions brought in by 'using' with direct member functions during parsing
of the class body.  To this point they've had a troublesome coexistence
which was resolved by set_class_bindings when the class is complete, but we
also need to handle lookup within the class body, such as in a trailing
return type.

The problem was that push_class_level_binding would either clobber the
using-decl with the direct members or vice-versa.  In older versions of GCC
we only pushed dependent usings, and preferring the dependent using made
sense, as it expresses a type-dependent overload set that we can't do
anything useful with.  But when we started keeping non-dependent usings
around, push_class_level_binding in particular wasn't adjusted accordingly.

This patch makes that adjustment, and pushes the functions imported by a
non-dependent using immediately from finish_member_declaration.  This made
diagnosing redundant using-decls a bit awkward, since we no longer push the
using-decl itself; I handle that by noticing when we try to add the same
function again and searching TYPE_FIELDS for the previous using-decl.

PR c++/92918
PR c++/104476

gcc/cp/ChangeLog:

* class.cc (add_method): Avoid adding the same used function twice.
(handle_using_decl): Don't add_method.
(finish_struct): Don't using op= if we have one already.
(maybe_push_used_methods): New.
* semantics.cc (finish_member_declaration): Call it.
* name-lookup.cc (diagnose_name_conflict): No longer static.
(push_class_level_binding): Revert 92918 patch, limit
to dependent using.
* cp-tree.h: Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/pr85070.C: Remove expected error.
* g++.dg/lookup/using66a.C: New test.
* g++.dg/lookup/using67.C: New test.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2021-06-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|9.4 |9.5

--- Comment #8 from Richard Biener  ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2021-05-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:decd38f99dd05eb54ddcaee7c52f21a56a844613

commit r10-9849-gdecd38f99dd05eb54ddcaee7c52f21a56a844613
Author: Jason Merrill 
Date:   Wed Apr 7 14:55:48 2021 -0400

c++: using overloaded with local decl [PR92918]

The problem here was that the lookup for 'impl' when parsing the template
only found the using-declaration, not the member function declaration.

This happened because when trying to add the member function declaration,
push_class_level_binding_1 saw that the current binding was a USING_DECL
and
the new value is an overload, and decided to just return success.

That 'return true' dates back to r69921.  In
https://gcc.gnu.org/pipermail/gcc-patches/2003-July/110632.html Nathan
mentions that we only push dependent USING_DECLs, which is no longer the
case; now that we retain more USING_DECLs, handling this case like the
other
overloaded function cases seems like the obvious solution.

gcc/cp/ChangeLog:

PR c++/92918
* name-lookup.c (push_class_level_binding_1): Do overload a new
function with a previous using-declaration.

gcc/testsuite/ChangeLog:

PR c++/92918
* g++.dg/lookup/using66.C: New test.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

2021-05-14 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.5 |9.4

--- Comment #6 from Jakub Jelinek  ---
GCC 8 branch is being closed.