public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction Date: Fri, 24 Mar 2023 18:51:36 +0000 [thread overview] Message-ID: <bug-106969-4-3Pj0ZSY3LL@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106969-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106969 --- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:bbf2424c57c2e13d1a972c4ef4e871c3119b9cb4 commit r13-6856-gbbf2424c57c2e13d1a972c4ef4e871c3119b9cb4 Author: Patrick Palka <ppalka@redhat.com> Date: Fri Mar 24 14:51:24 2023 -0400 c++: outer 'this' leaking into local class [PR106969] Here when resolving the implicit object for '&wrapped' within the local class Foo, we expect to obtain a dummy object of type Foo& since there's no 'this' available in this context. And yet at this point current_class_ref still corresponds to the outer class Context (and is const), which confuses maybe_dummy_object into propagating the cv-quals of current_class_ref and returning an object of type const Foo&. Thus decltype(&wrapped) wrongly yields const int* instead of int*. The problem ultimately seems to be that the 'this' from the enclosing class appears available for use when parsing the local class, but 'this' shouldn't persist across classes like that. This patch fixes this by clearing current_class_ptr/ref before parsing a class definition. After this change, for the test name-clash11.C in C++98 mode we would now complain about an invalid use of 'this' in e.g. ASSERT (sizeof (this->A) == 16); due to the way the test defines the ASSERT macro via a local class. This patch redefines the macro using a local typedef instead. PR c++/106969 gcc/cp/ChangeLog: * parser.cc (cp_parser_class_specifier): Clear current_class_ptr and current_class_ref sooner, before parsing a class definition. gcc/testsuite/ChangeLog: * g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in C++98 mode. * g++.dg/lookup/this2.C: New test.
next prev parent reply other threads:[~2023-03-24 18:51 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-19 17:13 [Bug c++/106969] New: " enolan at alumni dot cmu.edu 2022-09-19 17:30 ` [Bug c++/106969] [12/13 Regression] " pinskia at gcc dot gnu.org 2022-09-20 14:33 ` ppalka at gcc dot gnu.org 2022-10-18 8:43 ` rguenth at gcc dot gnu.org 2023-03-24 18:51 ` cvs-commit at gcc dot gnu.org [this message] 2023-03-24 18:52 ` [Bug c++/106969] [12 " ppalka at gcc dot gnu.org 2023-04-28 22:13 ` cvs-commit at gcc dot gnu.org 2023-04-28 22:15 ` ppalka at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106969-4-3Pj0ZSY3LL@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).