From patchwork Thu May 23 13:27:18 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathaniel Shead X-Patchwork-Id: 1938347 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=KYr4N7qG; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4VlTW91GTGz1ynR for ; Thu, 23 May 2024 23:27:49 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7351F3865490 for ; Thu, 23 May 2024 13:27:47 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by sourceware.org (Postfix) with ESMTPS id 0307A3858D38 for ; Thu, 23 May 2024 13:27:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0307A3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0307A3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716470847; cv=none; b=Y4NL0SD7qBkQ6r8HfP6PRIvj3ZAXzhS98G6mIiWtlLUz8pxc3bwbTnKXZHptTOt/Yv1nct3JSxB3QfWmYnVVi680VLc+3OvDQd1smrdYR8WEq9VBm9YslKRxMteIKiYF8Vj99O7fTW7XE1Th58DFSnj8KjtIqTbTIc3dXUDMqyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716470847; c=relaxed/simple; bh=L6IijXIKVR76qAKOomCROLfBBhBxgDrJsu15x2FLooo=; h=DKIM-Signature:Message-ID:Date:From:To:Subject:MIME-Version; b=fw2UVpsprWON6qS0Lhuz6QhRmLDVc58aJKVpSTWAMO2b13rM2GvRMWn9lPlN/VsOiLkQRJEblbcuGjEap9GjbQF1OKcrNx74Q8zV0NE+sElaouYQgXsU1Jh9FsRcivBnzT034eIFR/zxfgxaK7Ou/5Auptzh9H3jQfLhrkacdDU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5b27c5603ddso3762149eaf.1 for ; Thu, 23 May 2024 06:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716470844; x=1717075644; darn=gcc.gnu.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5k9K1vqEVS22/VzeGhFA2a1KjY82DJYiZm7NkZfrX4Y=; b=KYr4N7qGmzB8W/g3OCb6nScp2u5BKTd/ckTne1r51VFbdmQE8JDNG7PjQk4HepnpP2 IEjY8Zz1JNNQCbja4tp1NbkUUZyhnL/72/NPXOWl2eBEUEW4mFoJmrpMTAPnKlq6dStZ ZPkI4mmr6XVq/V90CgkNdAmX33YxlXkTpsxR+/zzdRM7JWsJgIsOn73Lhd0BuhZIT/6E uLg2D39moJd/PU8TcY4heBe3nmPqg73deQIiVNQmWxeHaRO0vj+kjX+Zth35JIZ7xLX4 C5yCqwjadlc9rV2zS9RBux7ShyqokGVn0qMDc8m5HFHvlCFaFhzJFaIYhWSz9RgcoCHK prfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716470844; x=1717075644; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5k9K1vqEVS22/VzeGhFA2a1KjY82DJYiZm7NkZfrX4Y=; b=UBRNEJmCpRFlhMqMMNJWuULaEemA59LXYs8Go8iMBdVG5QwThG2AE/GNlu37r9fbc3 iza1QQAHjeKU3vhS8I9auyH13BLwgAIXeQLc0a29shWE1OPOExdUrP0w1THfQXqW1My7 zlZxgClOo8ttW4xOoUURJzDQZAQNxM+ttP8B0iyuBuCm88wjaQJMkzfoThpmny/7dGne UUJ6Arii+IF6oh88cSfeDBILZYJo9/hWDWwWQXg0+wjg6RiL7+KiGNA4C6XayGx7nCWa fsr7kW+ArpP9wn8z2+p7RFoMk8TOnMEEUw+z/hRtpaV/ZarMUFQX18IZgvDm1i7EzMgU dmEw== X-Gm-Message-State: AOJu0YzaCNmlc0u70CSszZ098RNddB9IpSJhcpni/8JtcEwqbal2QgLq IU3bIyEFibgDrntQXLH+4lWpHFV+AougiDGcQbXkrXBbHGxHbS2t X-Google-Smtp-Source: AGHT+IF2Spdj0Ckm0Z62PGf/t+qfPCcdx/6rAxrx8HTskRkEt6CwusBB/8NkPGSK5aqj+a6x1hKV4w== X-Received: by 2002:a05:6358:cc16:b0:192:9d35:b027 with SMTP id e5c5f4694b2df-19791b77aa7mr411102555d.15.1716470843925; Thu, 23 May 2024 06:27:23 -0700 (PDT) Received: from Thaum. (14-200-72-253.tpgi.com.au. [14.200.72.253]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4d2a66590sm25089010b3a.1.2024.05.23.06.27.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 May 2024 06:27:23 -0700 (PDT) Message-ID: <664f443b.620a0220.3bb2.27d7@mx.google.com> X-Google-Original-Message-ID: Date: Thu, 23 May 2024 23:27:18 +1000 From: Nathaniel Shead To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell Subject: [PATCH 1/2] c++/modules: Fix treatment of unnamed types References: <664181e2.650a0220.dbfd8.e3d5@mx.google.com> <10d5ff7c-3d30-4317-97d9-91ea2370bbfa@redhat.com> <6646f5cb.170a0220.fb17d.75a5@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org On Mon, May 20, 2024 at 06:00:09PM -0400, Jason Merrill wrote: > On 5/17/24 02:14, Nathaniel Shead wrote: > > On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: > > > On 5/12/24 22:58, Nathaniel Shead wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > OK. > > > > > > > I realised as I was looking over this again that I might have spoken too > > soon with the header unit example being supported. Doing the following: > > > > // a.H > > struct { int y; } s; > > decltype(s) f(decltype(s)); // { dg-error "used but never defined" } > > inline auto x = f({ 123 }); > > // b.C > > struct {} unrelated; > > import "a.H"; > > decltype(s) f(decltype(s) x) { > > return { 456 + x.y }; > > } > > > > // c.C > > import "linkage-3_a.H"; > > int main() { auto a = x.y; } > > > > Actually does fail to link, because in 'c.C' we call 'f(.anon_0)' but > > the definition 'b.C' is f(.anon_1). > > > > I don't think this is fixable, so I don't think this direction is > > workable. > > Since namespace-scope anonymous types are TU-local, we don't need to support > that for proper modules, but it's not clear to me that we don't need to > support it for header units. > > OTOH, https://eel.is/c++draft/module#import-5.3 allows c.C to import a > different header unit than b.C, in which case the type is different and x > violates the odr. > Right; I think at this stage I don't know how to support this for header units (and even for module interface units it doesn't actually work; more on this below), so I think saying that this is actually an ODR violation is OK. > > That said, I think that it might still be worth making header modules > > satisfy 'module_has_cmi_p', since that is true to the name, and will be > > useful in other places we currently use 'module_p ()': in which case we > > could instead make all the callers in 'no_linkage_check' do > > 'module_maybe_has_cmi_p () && !header_module_p ()'; something like the > > following, perhaps? > > If we need that condition, it should be its own predicate rather than > expecting callers to do that combined check. > > But it's not clear to me how this is different from a type in the GMF of a > named module, which is exactly the maybe_has_cmi case; there we could again > see a different version of the type if another TU includes the header. > > Jason > This made me go back and double-check for named modules and it actually does fail as well; the following sample ICEs, even: export module M; struct {} s; int h(decltype(s)); int x = h(s); // ICE in write_unnamed_type_name, cp/mangle.cc:1806 So I think maybe the way to go here is to just not treat unnamed types as something that could possibly be accessed from a different TU, like the below. Then we don't need to do the special handling for header units, since as you say, they're not materially different anyway. Thoughts? (And I've moved the original change to 'module_has_cmi_p' to a separate patch given it's somewhat unrelated now.) Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and maybe 14.2)? -- >8 -- In r14-9530 we relaxed "depending on type with no-linkage" errors for declarations that could actually be accessed from different TUs anyway. However, this also enabled it for unnamed types, which never work. In a normal module interface, an unnamed type is TU-local by [basic.link] p15.2, and so cannot be exposed or the program is ill-formed. We don't yet implement this checking but we should assume that we will later; currently supporting this actually causes ICEs when attempting to create the mangled name in some situations. For a header unit, by [module.import] p5.3 it is unspecified whether two TUs importing a header unit providing such a declaration are importing the same header unit. In this case, we would require name mangling changes to somehow allow the (anonymous) type exported by such a header unit to correspond across different TUs in the presence of other anonymous declarations, so for this patch just assume that this case would be an ODR violation instead. gcc/cp/ChangeLog: * tree.cc (no_linkage_check): Anonymous types can't be accessed in a different TU. gcc/testsuite/ChangeLog: * g++.dg/modules/linkage-1_a.C: Remove anonymous type test. * g++.dg/modules/linkage-1_b.C: Likewise. * g++.dg/modules/linkage-1_c.C: Likewise. * g++.dg/modules/linkage-2.C: Add note about anonymous types. Signed-off-by: Nathaniel Shead Signed-off-by: Nathaniel Shead --- gcc/cp/tree.cc | 10 +--------- gcc/testsuite/g++.dg/modules/linkage-1_a.C | 4 ---- gcc/testsuite/g++.dg/modules/linkage-1_b.C | 1 - gcc/testsuite/g++.dg/modules/linkage-1_c.C | 1 - gcc/testsuite/g++.dg/modules/linkage-2.C | 9 +++++---- 5 files changed, 6 insertions(+), 19 deletions(-) diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc index 9d37d255d8d..e2d0d3229c1 100644 --- a/gcc/cp/tree.cc +++ b/gcc/cp/tree.cc @@ -3016,15 +3016,7 @@ no_linkage_check (tree t, bool relaxed_p) /* Only treat unnamed types as having no linkage if they're at namespace scope. This is core issue 966. */ if (TYPE_UNNAMED_P (t) && TYPE_NAMESPACE_SCOPE_P (t)) - { - if (relaxed_p - && TREE_PUBLIC (CP_TYPE_CONTEXT (t)) - && module_maybe_has_cmi_p ()) - /* This type could possibly be accessed outside this TU. */ - return NULL_TREE; - else - return t; - } + return t; for (r = CP_TYPE_CONTEXT (t); ; ) { diff --git a/gcc/testsuite/g++.dg/modules/linkage-1_a.C b/gcc/testsuite/g++.dg/modules/linkage-1_a.C index 750e31ff347..1d81312e94f 100644 --- a/gcc/testsuite/g++.dg/modules/linkage-1_a.C +++ b/gcc/testsuite/g++.dg/modules/linkage-1_a.C @@ -9,7 +9,3 @@ auto f() { } decltype(f()) g(); // { dg-warning "used but not defined" "" { target c++17_down } } export auto x = g(); - -struct {} s; -decltype(s) h(); // { dg-warning "used but not defined" "" { target c++17_down } } -export auto y = h(); diff --git a/gcc/testsuite/g++.dg/modules/linkage-1_b.C b/gcc/testsuite/g++.dg/modules/linkage-1_b.C index f23962d76b7..5bc0d1b888d 100644 --- a/gcc/testsuite/g++.dg/modules/linkage-1_b.C +++ b/gcc/testsuite/g++.dg/modules/linkage-1_b.C @@ -3,4 +3,3 @@ module M; decltype(f()) g() { return {}; } -decltype(s) h() { return {}; } diff --git a/gcc/testsuite/g++.dg/modules/linkage-1_c.C b/gcc/testsuite/g++.dg/modules/linkage-1_c.C index f1406b99032..9ff1491b67e 100644 --- a/gcc/testsuite/g++.dg/modules/linkage-1_c.C +++ b/gcc/testsuite/g++.dg/modules/linkage-1_c.C @@ -5,5 +5,4 @@ import M; int main() { auto a = x; - auto b = y; } diff --git a/gcc/testsuite/g++.dg/modules/linkage-2.C b/gcc/testsuite/g++.dg/modules/linkage-2.C index eb4d7b051af..f69bd7ff728 100644 --- a/gcc/testsuite/g++.dg/modules/linkage-2.C +++ b/gcc/testsuite/g++.dg/modules/linkage-2.C @@ -13,14 +13,15 @@ namespace { return A{}; } decltype(f()) g(); // { dg-error "used but never defined" } - - struct {} s; - decltype(s) h(); // { dg-error "used but never defined" } } export void use() { g(); - h(); } +// Additionally, unnamed types have no linkage but are also TU-local, +// and thus cannot be in a module interface unit. +// We don't yet implement this checking however. +struct {} s; // { dg-error "TU-local" "" { xfail *-*-* } } + // { dg-prune-output "not writing module" } From patchwork Thu May 23 13:29:06 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathaniel Shead X-Patchwork-Id: 1938349 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=PpICDIWX; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4VlTYM17L3z1ynR for ; Thu, 23 May 2024 23:29:43 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5FDB7384C2C2 for ; Thu, 23 May 2024 13:29:41 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 995603858C62 for ; Thu, 23 May 2024 13:29:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 995603858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 995603858C62 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716470956; cv=none; b=i36Bw43/UM3erhx+z7FmKA62SJ6Iz13HyUpGK8u70tNcqgvdvPYkQQcH4zyBLnAwMXpUpSHRaoU2COcq9ON8ualPyui54Bc8b5EigAenH4DBbeKuadrLcYbCB9Tt/AiRxB2Pd6yIYHxDGxPTeijy41rfW5UwF3YZAfOsDCzQgRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716470956; c=relaxed/simple; bh=IjEJeEdJBifmmn2m7c8SNAbXRCxxnDTDuc8yk1EOffs=; h=DKIM-Signature:Message-ID:Date:From:To:Subject:MIME-Version; b=U4GS5lQ1m5JB0zlqz8eQ8Zik0N8uurU7kxkB4kfvgpcFZ80AGzFDAiQBbmKaAzM5A3Al9fYbXSaBWDzY/zBMwYaSY8qz75C0uC45M8CHZTW2NwFVJhsTIB6X0JUfHzDowBNgeqnhHqu1tOf5u1JHFBoT3aV+zG7swoeY8VzugOs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1ee0132a6f3so17879965ad.0 for ; Thu, 23 May 2024 06:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716470951; x=1717075751; darn=gcc.gnu.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=sE5bB7xqdp6YhTIAfkQRjrz9VxnlizmhDkX0zR0nVMA=; b=PpICDIWXaEFU4rT8km9a1yXoqhLnpA+iA4i3ogynEJUfioQwb1K674OK5aR+8PA7rk mLnAFHzzWSbv3v7L5DoGngTlwyckdEhRvunVPR5lDeZ5EYylAXDmSnc8ZIC6dV8t+8cr zPu/DqaaVkJQrq3HKOnGO6f3/G6WsBIGBd20T2yNsgYvDqxBkVao9Cpbnn6mGQzIyVSD ztElSUZbaseA2W7nH7bJncXPiTSAp4BVgst+6GfS46sXCYcEC8VKGQ39IC37v+A8/URA Z2Hi+rE1Gv/q7TMdrhI8eJs9wWlqF3vvRX5yFSHemOId1lk2RMVo1AjAeZERxom135FF 9wAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716470951; x=1717075751; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sE5bB7xqdp6YhTIAfkQRjrz9VxnlizmhDkX0zR0nVMA=; b=qRr+wyByb5SvSI9cMRODh5J5MAgV7ugH7Plcr1tCN1VWezzxlyKE5qcHWis6dRXOxU aZphZKtFQr3Ft98gaWzAWpX2DEAAwDnUx299/yiwjHHAiJcqRRJYuR6DmQYg9vZl6uN7 2QPFs87p841BuSBhX9HxoUdQJUYg9rPPKBvDI32vLndzBIZovUP9JbHn2Niy3giLhK+V xdr+hl2bnpUHBT61sTZZ1YwD1hD5lmgNJxRPREk8Iocffgp3XmqKTtmrwwlR66Of9n62 JZXHlg+KWTvRCm1XNNV/f/M7JvaMAzXbFYxrfYJ97uS2py33eSmboxjyULWiTjyES4WK xCBQ== X-Gm-Message-State: AOJu0Yw0cP85YeWKWGypJioGh5ezFmXPyKWOOMyN2Aa433qfWAance3a OwN/MiraHyYhS555WVSOwcnRIxpqZ3w1DuPgIg8NslW6z9RgbIb9 X-Google-Smtp-Source: AGHT+IEvMCxsWWwcR8DMNB+76ZUnFSxO4jgaFiQ8R1L3k7s0UvE56AOtoyBptpIk7ewm2OxrXs6fsg== X-Received: by 2002:a17:902:ce0c:b0:1f3:220f:f317 with SMTP id d9443c01a7336-1f3220ff423mr58253065ad.35.1716470951375; Thu, 23 May 2024 06:29:11 -0700 (PDT) Received: from Thaum. (14-200-72-253.tpgi.com.au. [14.200.72.253]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0c036272sm255663425ad.188.2024.05.23.06.29.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 May 2024 06:29:10 -0700 (PDT) Message-ID: <664f44a6.170a0220.7a70.2e85@mx.google.com> X-Google-Original-Message-ID: Date: Thu, 23 May 2024 23:29:06 +1000 From: Nathaniel Shead To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell Subject: [PATCH 2/2] c++/modules: Remember that header units have CMIs References: <664181e2.650a0220.dbfd8.e3d5@mx.google.com> <10d5ff7c-3d30-4317-97d9-91ea2370bbfa@redhat.com> <6646f5cb.170a0220.fb17d.75a5@mx.google.com> <664f443b.620a0220.3bb2.27d7@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <664f443b.620a0220.3bb2.27d7@mx.google.com> X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org And here's that patch. As far as I can tell there should be no visible change anymore, so there aren't any testcases. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- This appears to be an oversight in the definition of module_has_cmi_p. This change will allow us to use the function directly in more places that need to additional work only if generating a module CMI in the future, allowing us to do additional work only when we know we need it. gcc/cp/ChangeLog: * cp-tree.h (module_has_cmi_p): Also include header units. (module_maybe_has_cmi_p): Update comment. * module.cc (set_defining_module): Only need to track declarations for later exporting if the module may have a CMI. * name-lookup.cc (pushdecl): Likewise. Signed-off-by: Nathaniel Shead --- gcc/cp/cp-tree.h | 7 +++---- gcc/cp/module.cc | 2 +- gcc/cp/name-lookup.cc | 2 +- 3 files changed, 5 insertions(+), 6 deletions(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index ba9e848c177..9472759d3c8 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -7381,7 +7381,7 @@ inline bool module_interface_p () inline bool module_partition_p () { return module_kind & MK_PARTITION; } inline bool module_has_cmi_p () -{ return module_kind & (MK_INTERFACE | MK_PARTITION); } +{ return module_kind & (MK_INTERFACE | MK_PARTITION | MK_HEADER); } inline bool module_purview_p () { return module_kind & MK_PURVIEW; } @@ -7393,9 +7393,8 @@ inline bool named_module_purview_p () inline bool named_module_attach_p () { return named_module_p () && module_attach_p (); } -/* We don't know if this TU will have a CMI while parsing the GMF, - so tentatively assume that it might, for the purpose of determining - whether no-linkage decls could be used by an importer. */ +/* Like module_has_cmi_p, but tentatively assumes that this TU may have a + CMI if we haven't seen the module-declaration yet. */ inline bool module_maybe_has_cmi_p () { return module_has_cmi_p () || (named_module_p () && !module_purview_p ()); } diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc index 520dd710549..8639ed6f1a2 100644 --- a/gcc/cp/module.cc +++ b/gcc/cp/module.cc @@ -19216,7 +19216,7 @@ set_defining_module (tree decl) gcc_checking_assert (!DECL_LANG_SPECIFIC (decl) || !DECL_MODULE_IMPORT_P (decl)); - if (module_p ()) + if (module_maybe_has_cmi_p ()) { /* We need to track all declarations within a module, not just those in the module purview, because we don't necessarily know yet if diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc index 78f08acffaa..f1f8c19feb1 100644 --- a/gcc/cp/name-lookup.cc +++ b/gcc/cp/name-lookup.cc @@ -4103,7 +4103,7 @@ pushdecl (tree decl, bool hiding) if (level->kind == sk_namespace && TREE_PUBLIC (level->this_entity) - && module_p ()) + && module_maybe_has_cmi_p ()) maybe_record_mergeable_decl (slot, name, decl); } }