From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A01253858D28 for ; Thu, 5 Jan 2023 18:18:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A01253858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672942723; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9gw4Bq0aFtX8arhpZ/V3ghBUncO+vTp7KLo4KlivKbI=; b=B+hf3/KhnnWkuiL7DxgGFmUzKy5bYl2yaGunfHnHk1ZMRqpChHgSoyLjvJx09P54VOrl1G jANsocGZCk+CTmm00rIVEKd89NDZsGsYRQYNiO314659KznrRafr6m4jyFRDpvAtarm5LK ePgB0cz0ksKdF+ysl8bVmTiK9m87PPw= Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-473-TS-DvreWO2KL0siCY04MeA-1; Thu, 05 Jan 2023 13:18:42 -0500 X-MC-Unique: TS-DvreWO2KL0siCY04MeA-1 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-487b0bf1117so236911207b3.5 for ; Thu, 05 Jan 2023 10:18:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9gw4Bq0aFtX8arhpZ/V3ghBUncO+vTp7KLo4KlivKbI=; b=jwWRC6wJFzZnQip8yjetIaNu1DShiseTjlo2jq/DNPouARUupPAcAGh4UUB9tWs4nn 0bD7UTn5xzkbD/9niCBmzisONMn8/WZDmpI8UYbFCuedbPMVuCwRaXqpQib3BXAGz6wD hnroZDBhzASg/DucnPRN8CgwE9DtQNiY0hpyJYOlchNpX+X1jGfrWLQrlgeJcg7/SeEw yLtL1thZCA9RJu4pxES6E9ITMx7y9wA0xxizdsFmOX17AZuCIT8faUyLAMGMgb9iEqFi rkuUkII9gWbgUySb+EV9ZrxU2WjddkTQtXhKZwwSInWrviiVCjEhWnQiTeZa//R5xEOW w5Ng== X-Gm-Message-State: AFqh2kobqkCVZA6lDkkQSf0fgWqv7wxwtdMc2m+DiWievNCOjmP1phyW +T6qTBEsKOZep2AGLHeawuUvathriNpSQv5z4igyoy4y9+Mqmvdo8EfQBXkkpdaHXrVGeVjaor4 RfsL0IR8ELJC2j9/p8g== X-Received: by 2002:a0d:d494:0:b0:364:1ba1:4bd2 with SMTP id w142-20020a0dd494000000b003641ba14bd2mr114211ywd.43.1672942721658; Thu, 05 Jan 2023 10:18:41 -0800 (PST) X-Google-Smtp-Source: AMrXdXvJsHVc+KoJeHksApUc08ThaobC00c5hUzLk2+MY1mVl77kSSYUFuJaad5ERqqC1y/jvDeRqA== X-Received: by 2002:a0d:d494:0:b0:364:1ba1:4bd2 with SMTP id w142-20020a0dd494000000b003641ba14bd2mr114193ywd.43.1672942721398; Thu, 05 Jan 2023 10:18:41 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id q26-20020a05620a2a5a00b00704df12317esm23443884qkp.24.2023.01.05.10.18.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 10:18:40 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 5 Jan 2023 13:18:40 -0500 (EST) To: Patrick Palka cc: gcc-patches@gcc.gnu.org, jason@redhat.com Subject: Re: [PATCH] c++: class-head parsing and CPP_TEMPLATE_ID access [PR108275] In-Reply-To: <20230105172010.3598077-1-ppalka@redhat.com> Message-ID: References: <20230105172010.3598077-1-ppalka@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 5 Jan 2023, Patrick Palka wrote: > When tentatively parsing what is really an elaborated-type-specifier > first as a class-specifier, we may form a CPP_TEMPLATE_ID token that > later gets reused in the fallback parse if the tentative parse fails. > These special tokens also capture the access checks that have been > deferred while parsing the template-id. But here, we form such a token > when the access check state is dk_no_check, and so the token captures > no access checks. This effectively bypasses access checking for the > template-id during the subsequent parse as an elaborated-type-specifier. > > This patch fixes this by using dk_deferred instead of dk_no_check when > parsing the class name. Looks like this issue isn't specific to the CPP_TEMPLATE_ID mechanism -- using dk_no_check also means we bypass access checking during satisfaction too: template requires T::value struct A { }; struct B { private: static constexpr bool value = true; }; struct A a; // incorrectly accepted > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? > > PR c++/108275 > > gcc/cp/ChangeLog: > > * parser.cc (cp_parser_class_head): Use dk_deferred instead of > dk_no_check when parsing the class name. > > gcc/testsuite/ChangeLog: > > * g++.dg/parse/access14.C: New test. > --- > gcc/cp/parser.cc | 23 +++++++++++++++++------ > gcc/testsuite/g++.dg/parse/access14.C | 18 ++++++++++++++++++ > 2 files changed, 35 insertions(+), 6 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/parse/access14.C > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc > index bfd8aeae39f..8b1658decba 100644 > --- a/gcc/cp/parser.cc > +++ b/gcc/cp/parser.cc > @@ -26559,7 +26559,23 @@ cp_parser_class_head (cp_parser* parser, > if (cp_parser_global_scope_opt (parser, /*current_scope_valid_p=*/false)) > qualified_p = true; > > - push_deferring_access_checks (dk_no_check); > + /* It is OK to define an inaccessible class; for example: > + > + class A { class B; }; > + class A::B {}; > + > + So we want to ignore access when parsing the class name. > + However, we might be tentatively parsing what is really an > + elaborated-type-specifier naming a template-id, e.g. > + > + struct C<&D::m> c; > + > + In this case the tentative parse as a class-head will fail, but not > + before cp_parser_template_id splices in a CPP_TEMPLATE_ID token. > + Since dk_no_check is sticky, we must instead use dk_deferred so that > + any such CPP_TEMPLATE_ID token created during this tentative parse > + will correctly capture the access checks imposed by the template-id . */ > + push_deferring_access_checks (dk_deferred); > > /* Determine the name of the class. Begin by looking for an > optional nested-name-specifier. */ > @@ -26586,11 +26602,6 @@ cp_parser_class_head (cp_parser* parser, > The proposed resolution for Core Issue 180 says that wherever > you see `class T::X' you should treat `X' as a type-name. > > - It is OK to define an inaccessible class; for example: > - > - class A { class B; }; > - class A::B {}; > - > We do not know if we will see a class-name, or a > template-name. We look for a class-name first, in case the > class-name is a template-id; if we looked for the > diff --git a/gcc/testsuite/g++.dg/parse/access14.C b/gcc/testsuite/g++.dg/parse/access14.C > new file mode 100644 > index 00000000000..bdbc7f6ee2b > --- /dev/null > +++ b/gcc/testsuite/g++.dg/parse/access14.C > @@ -0,0 +1,18 @@ > +// PR c++/108275 > + > +struct A { > + int i; > +private: > + int j; > +}; > + > +template > +struct B { > + struct C { }; > +private: > + template struct D { }; > +}; > + > +struct B<&A::j> b; // { dg-error "private" } > +struct B<&A::j>::C c; // { dg-error "private" } > +struct B<&A::i>::D<0> d; // { dg-error "private" } > -- > 2.39.0.189.g4dbebc36b0 > >