[Bug 255374] C++20 features (headers) std::concepts, std::format, std::numbers, std::source_location, etc. are missing

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255374

--- 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=libstdc++ 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.