Date: Sun, 21 May 2023 22:17:15 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 255374] C++20 features (headers) std::concepts, std::format, std::numbers, std::source_location, etc. are missing Message-ID: <bug-255374-99-Ur9i7B3rK8@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255374-99@https.bugs.freebsd.org/bugzilla/> References: <bug-255374-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255374 --- Comment #28 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Dimitry Andric from comment #15) LLVM 15+ has changed to using __has_feature(experimental_library) notation as an overall control of the likes of, for example, the incomplete format and range library features: . . . # if __has_feature(experimental_library) # ifndef _LIBCPP_ENABLE_EXPERIMENTAL # define _LIBCPP_ENABLE_EXPERIMENTAL # endif # endif // Incomplete features get their own specific disabling flags. This makes it // easier to grep for target specific flags once the feature is complete. # if !defined(_LIBCPP_ENABLE_EXPERIMENTAL) && !defined(_LIBCPP_BUILDING_LIBRARY) # define _LIBCPP_HAS_NO_INCOMPLETE_FORMAT # define _LIBCPP_HAS_NO_INCOMPLETE_RANGES # endif Given that, is there an expectation for a default status for if FreeBSD will include vs. exclude the experimental libraries as things go forward? It seems that LLVM 15 was handled as an "exclude", as an example. Avoiding potential ABI incompatibilities with later non-experimental features would point in that direction. Part of the reason that this comes up as a question is the lack of non-system clang-based C++ library implementations. Using devel/llvm16 does not get one the updated C++ library implementation, for example. Also, the environment does not support using -stdlib=3Dlibstdc++ in clang. It might help if the expected C++ library status was more explicit/up-front relative to clang++ use in FreeBSD. That might lead to less "what about" questioning (that is generally not about what can be involved in building FreeBSD but, instead, about non-FreeBSD-internal code that is to be built). Generally, the language implementation completes before the library for the same standard does. clang 5 claims to cover the C++17 language, not the library, for example. The C++17 library is mostly --but still not fully-- covered, for example, not even in clang++ 16 with its libc++ vintage. The problem is historically more about the library status. I suppose this sort of thing could end up with a FreeBSD-arch discussion if it has been left implicit so far. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255374-99-Ur9i7B3rK8>