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.133.124]) by sourceware.org (Postfix) with ESMTPS id 74F9D3858D28 for ; Thu, 16 Dec 2021 16:29:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74F9D3858D28 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-368-NiHu5qnjO6W_cgxcdQB3pw-1; Thu, 16 Dec 2021 11:28:59 -0500 X-MC-Unique: NiHu5qnjO6W_cgxcdQB3pw-1 Received: by mail-qt1-f197.google.com with SMTP id h20-20020ac85e14000000b002b2e9555bb1so34164532qtx.3 for ; Thu, 16 Dec 2021 08:28:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=AFsfRGW0lDMumiVA1G77TBBPp9fSZkKWN4B+VA84FSQ=; b=Z9N3r6Lj2YPPnTgH8Vsq2BiQnO0yCBKebWxxecWmkfsNIWWq/1SUnhLpRmua4mfjSz 2AzFfF50fDV/5mAtG2Yt8RfGki0lrNlvahzXotTe4yZxmdrJQVTRoBKNbFSDisuPMHZ1 IQSBJQTKg2iamhoHYFn9vh7wZfevbAaBo2zLzeIQ1wkkHFzaAMJI3LIqUmV2GskrCgKq ZdH4t29JMU0OMhr4nVRkyCRJtVq+xibpxOhaVqSzgU+KZE/s1IfF+ZLlxDa4yeSzodUV YG+LpGQHtEUeOeJX4yXGT5E+t9MYLhyL+TSyZcAg5A2VZFJb2BB7dWCHC0G7GQZGFGj3 vDIg== X-Gm-Message-State: AOAM530FEMUpEESE15q+iQCVcMuqBOtQ3iyUsPALBnO7HxjzRbyE9QbF B0R49wAsI7+LQe20Lp2ub4X2q/NTJQdm2FdZWpqZRqjJQJRhxbmYIp+pfu7nTR6NDtQXX2Lu39+ h8hFYnRWjCJaNZcyrwA== X-Received: by 2002:a05:620a:440d:: with SMTP id v13mr12213479qkp.597.1639672138541; Thu, 16 Dec 2021 08:28:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJzkp/kq9cKDuZWwscw+zSyIXO+94GGbLpMdruxEkmdTAacyuAdANkpwWf+WloJxkQMAu7q/Kw== X-Received: by 2002:a05:620a:440d:: with SMTP id v13mr12213459qkp.597.1639672138248; Thu, 16 Dec 2021 08:28:58 -0800 (PST) Received: from [192.168.1.130] (ool-18e40894.dyn.optonline.net. [24.228.8.148]) by smtp.gmail.com with ESMTPSA id l9sm3036091qkj.37.2021.12.16.08.28.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Dec 2021 08:28:57 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 16 Dec 2021 11:28:56 -0500 (EST) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: nested lambda capturing a capture proxy, part 2 [PR94376] In-Reply-To: <0594bc89-b458-13f2-047f-745da5ff23ca@redhat.com> Message-ID: References: <20211215203612.4095222-1-ppalka@redhat.com> <0594bc89-b458-13f2-047f-745da5ff23ca@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=-15.0 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_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 16:29:01 -0000 On Wed, 15 Dec 2021, Jason Merrill wrote: > On 12/15/21 15:36, Patrick Palka wrote: > > The r12-5403 fix apparently doesn't handle the case where the inner > > lambda explicitly rather implicitly captures the capture proxy from > > the outer lambda, and so we still reject the first example in the > > testcase below. > > > > The reason is that compared to an implicit capture, the effective > > initializer for an explicit capture is wrapped in a location wrapper > > (pointing to the source location of the explicit capture), and this > > wrapper foils the is_capture_proxy check. The simplest fix appears to > > be to strip location wrappers accordingly. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk? > > > > PR c++/94376 > > > > gcc/cp/ChangeLog: > > > > * lambda.c (lambda_capture_field_type): Strip location wrappers > > before checking for a capture proxy. > > I think either is_capture_proxy should strip location wrappers or > gcc_checking_assert that it doesn't see one. Good idea, here's v2 which adds an assert to is_capture_proxy. Only one other caller, mark_const_cap_r, had to be adjusted. -- >8 -- The r12-5403 fix apparently doesn't handle the case where the inner lambda explicitly rather implicitly captures the capture proxy from the outer lambda, which causes us to reject the first example in the testcase below. This is because compared to an implicit capture, the effective initializer for an explicit capture is wrapped in a location wrapper (pointing to the capture list), and this wrapper foils the is_capture_proxy check added in r12-5403. The simplest fix appears to be to strip location wrappers accordingly before checking is_capture_proxy. To help prevent against other occurrences of this kind of bug, this patch also makes is_capture_proxy assert it doesn't see a location wrapper. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/94376 gcc/cp/ChangeLog: * lambda.c (lambda_capture_field_type): Strip location wrappers before checking for a capture proxy. (is_capture_proxy): Assert that we don't see a location wrapper. (mark_const_cap_r): Don't call is_constant_capture_proxy on a location wrapper. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-nested9a.C: New test. --- gcc/cp/lambda.c | 7 ++++ .../g++.dg/cpp0x/lambda/lambda-nested9a.C | 42 +++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c index c39a2bca416..d14e12c48f0 100644 --- a/gcc/cp/lambda.c +++ b/gcc/cp/lambda.c @@ -221,6 +221,7 @@ lambda_capture_field_type (tree expr, bool explicit_init_p, } else { + STRIP_ANY_LOCATION_WRAPPER (expr); if (!by_reference_p && is_capture_proxy (expr)) { /* When capturing by-value another capture proxy from an enclosing @@ -246,6 +247,10 @@ lambda_capture_field_type (tree expr, bool explicit_init_p, bool is_capture_proxy (tree decl) { + /* Location wrappers should be stripped or otherwise handled by the + caller before using this predicate. */ + gcc_checking_assert (!location_wrapper_p (decl)); + return (VAR_P (decl) && DECL_HAS_VALUE_EXPR_P (decl) && !DECL_ANON_UNION_VAR_P (decl) @@ -1496,6 +1501,8 @@ mark_const_cap_r (tree *t, int *walk_subtrees, void *data) *walk_subtrees = 0; } } + else if (location_wrapper_p (*t)) + /* is_capture_proxy dislikes location wrappers. */; else if (is_constant_capture_proxy (*t)) var = DECL_CAPTURED_VARIABLE (*t); diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C new file mode 100644 index 00000000000..d62f8f0c952 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C @@ -0,0 +1,42 @@ +// PR c++/94376 +// Like lambda-nested9.C but using explicit captures in the inner lambda. +// { dg-do compile { target c++11 } } + +int main() { + // We used to incorrectly reject the first two cases. + int i = 0; + [=] () { + [i] () mutable { + ++i; + }; + }; + +#if __cpp_init_captures + [j=0] () { + [j] () mutable { + ++j; + }; + }; +#endif + + [=] () { + [&i] () mutable { + ++i; // { dg-error "read-only" } + }; + }; + + const int j = 0; + [=] () { + [j] () mutable { + ++j; // { dg-error "read-only" } + }; + }; + +#if __cpp_init_captures + [j=0] () { + [&j] () mutable { + ++j; // { dg-error "read-only" "" { target c++14 } } + }; + }; +#endif +} -- 2.34.1.297.g69a9c10c95