On Sat, 15 Nov 2025 at 08:47 +0000, Jonathan Wakely wrote:
On Fri, 14 Nov 2025 at 19:37 -0500, Marek Polacek wrote:
diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/std.cc.in
index 27d83f1ba1b..a75db1fe0a0 100644
--- a/libstdc++-v3/src/c++23/std.cc.in
+++ b/libstdc++-v3/src/c++23/std.cc.in
@@ -2035,6 +2035,261 @@ export namespace std::pmr
using std::pmr::unsynchronized_pool_resource;
}
+// <meta>
+#if __glibcxx_reflection >= 202506L
+export namespace std
+{
+#if __has_builtin(__builtin_is_string_literal)
+ using std::is_string_literal;
+#endif
+ using std::define_static_string;
+ using std::define_static_array;
+ using std::define_static_object;
+ namespace meta
+ {
+ using std::meta::info;
+ using std::meta::exception;
+ using std::meta::operators;
+ using enum std::meta::operators;
This is enough to export all the enumerators of this enum, right?
Hmm, we don't do this for other enums such as
std::filesystem::file_type, which might be a bug in the existing
exports...
Ah, but that's because those other enumerators are not supposed to be
usable as members of std::filesystem, unlike the meta::operators
enumerators, which are usable as meta::op_new in addition to
meta::operators::op_new.
The filesystem enumerators have to be qualified with the enum name
e.g. filesystem::file_type::directory, not filesystem::directory.
So we don't have a problem with the existing exports for the rest of
the library.
