https://gcc.gnu.org/g:0173dcce92baa62a74929814a75edb75eeab1a54
commit r15-822-g0173dcce92baa62a74929814a75edb75eeab1a54
Author: Nathaniel Shead <nathanielosh...@gmail.com>
Date: Thu May 23 22:50:58 2024 +1000
c++/modules: Fix treatment of unnamed types
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 <nathanielosh...@gmail.com>
Reviewed-by: Jason Merrill <ja...@redhat.com>
Diff:
---
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 | 6 ++++++
5 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 0485a618c6c..fe3f034d000 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2988,15 +2988,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..d913d6a30fc 100644
--- a/gcc/testsuite/g++.dg/modules/linkage-2.C
+++ b/gcc/testsuite/g++.dg/modules/linkage-2.C
@@ -23,4 +23,10 @@ export void use() {
h();
}
+// Additionally, unnamed types have no linkage but are also TU-local, and thus
+// cannot be exposed in a module interface unit. The non-TU-local entity 's'
+// here is an exposure of this type, so this should be an error; we don't yet
+// implement this checking however.
+struct {} s; // { dg-error "TU-local" "" { xfail *-*-* } }
+
// { dg-prune-output "not writing module" }
