public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/92918] [8/9/10/11 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
@ 2021-04-07 19:27 ` cvs-commit at gcc dot gnu.org
  2021-04-07 19:28 ` [Bug c++/92918] [8/9/10 " jason at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-07 19:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

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

commit r11-8033-ga528594cf9a74e5a0fbac13ef673064ed73e1b89
Author: Jason Merrill <jason@redhat.com>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [8/9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
  2021-04-07 19:27 ` [Bug c++/92918] [8/9/10/11 Regression] Does not do name lookup when using from base class cvs-commit at gcc dot gnu.org
@ 2021-04-07 19:28 ` jason at gcc dot gnu.org
  2021-05-14  9:52 ` [Bug c++/92918] [9/10 " jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2021-04-07 19:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jason at gcc dot gnu.org
      Known to work|                            |11.0
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
            Summary|[8/9/10/11 Regression] Does |[8/9/10 Regression] Does
                   |not do name lookup when     |not do name lookup when
                   |using from base class       |using from base class

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for 11 so far.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
  2021-04-07 19:27 ` [Bug c++/92918] [8/9/10/11 Regression] Does not do name lookup when using from base class cvs-commit at gcc dot gnu.org
  2021-04-07 19:28 ` [Bug c++/92918] [8/9/10 " jason at gcc dot gnu.org
@ 2021-05-14  9:52 ` jakub at gcc dot gnu.org
  2021-05-20 21:35 ` cvs-commit at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-05-14  9:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2021-05-14  9:52 ` [Bug c++/92918] [9/10 " jakub at gcc dot gnu.org
@ 2021-05-20 21:35 ` cvs-commit at gcc dot gnu.org
  2021-06-01  8:15 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-05-20 21:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jason Merrill
<jason@gcc.gnu.org>:

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

commit r10-9849-gdecd38f99dd05eb54ddcaee7c52f21a56a844613
Author: Jason Merrill <jason@redhat.com>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2021-05-20 21:35 ` cvs-commit at gcc dot gnu.org
@ 2021-06-01  8:15 ` rguenth at gcc dot gnu.org
  2022-03-18 18:08 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-01  8:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2021-06-01  8:15 ` rguenth at gcc dot gnu.org
@ 2022-03-18 18:08 ` cvs-commit at gcc dot gnu.org
  2022-04-12  3:57 ` cvs-commit at gcc dot gnu.org
  2022-05-12 13:18 ` jason at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-03-18 18:08 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

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

commit r12-7714-g47da5198766256be658b4c321cecfd6039b0b91b
Author: Jason Merrill <jason@redhat.com>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2022-03-18 18:08 ` cvs-commit at gcc dot gnu.org
@ 2022-04-12  3:57 ` cvs-commit at gcc dot gnu.org
  2022-05-12 13:18 ` jason at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-12  3:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

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

commit r12-8098-g4195fced8a13422db94e179404588d9d887a036a
Author: Jason Merrill <jason@redhat.com>
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
       [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2022-04-12  3:57 ` cvs-commit at gcc dot gnu.org
@ 2022-05-12 13:18 ` jason at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: jason at gcc dot gnu.org @ 2022-05-12 13:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |11.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-05-12 13:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-92918-4@http.gcc.gnu.org/bugzilla/>
2021-04-07 19:27 ` [Bug c++/92918] [8/9/10/11 Regression] Does not do name lookup when using from base class cvs-commit at gcc dot gnu.org
2021-04-07 19:28 ` [Bug c++/92918] [8/9/10 " jason at gcc dot gnu.org
2021-05-14  9:52 ` [Bug c++/92918] [9/10 " jakub at gcc dot gnu.org
2021-05-20 21:35 ` cvs-commit at gcc dot gnu.org
2021-06-01  8:15 ` rguenth at gcc dot gnu.org
2022-03-18 18:08 ` cvs-commit at gcc dot gnu.org
2022-04-12  3:57 ` cvs-commit at gcc dot gnu.org
2022-05-12 13:18 ` jason at gcc dot gnu.org

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).