See https://en.cppreference.com/w/cpp/utility/format/format
The llvm repository has many c++20 features: * format: https://github.com/llvm/llvm-project/blob/main/libcxx/include/format * ranges: https://github.com/llvm/llvm-project/blob/main/libcxx/include/ranges Should it just be merged?
Both format and ranges are still being worked on upstream, and have not yet been merged to the 12.0 branch, likely because they are not yet ready for public consumption. I would rather wait until upstream officially puts these in the 12.0 branch, or until 13.0 comes out.
Created attachment 225518 [details] Install new C++ header files We added barrier, concepts, execution, latch, numbers, and semaphore with r363742 but they were never installed properly. https://cgit.freebsd.org/src/commit/contrib/llvm-project/libcxx/include?id=5ffd83dbcc34f10e07f6d3e968ae6365869615f4 I don't know about format, etc. but we should install what we have, IMHO.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=95aa617e4bf09fcc813b1bab3d0dbf4b606807b1 commit 95aa617e4bf09fcc813b1bab3d0dbf4b606807b1 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-06-03 18:53:18 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-06-03 18:53:18 +0000 Add C++ headers <barrier> <concepts> <execution> <latch> <numbers> <semaphore> I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days lib/libc++/Makefile | 6 +++++ tools/build/mk/OptionalObsoleteFiles.inc | 43 ++++++++++++++++++++------------ 2 files changed, 33 insertions(+), 16 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=70e13c4cffd5ff7a70296bc5c4c3b7525c278b1d commit 70e13c4cffd5ff7a70296bc5c4c3b7525c278b1d Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-06-03 18:53:18 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-06-06 11:41:34 +0000 Add C++ headers <barrier> <concepts> <execution> <latch> <numbers> <semaphore> I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days (cherry picked from commit 95aa617e4bf09fcc813b1bab3d0dbf4b606807b1) lib/libc++/Makefile | 6 +++++ tools/build/mk/OptionalObsoleteFiles.inc | 43 ++++++++++++++++++++------------ 2 files changed, 33 insertions(+), 16 deletions(-)
Fixes committed to main and stable/13. Does anybody feel that these are important enough to warrant an Errata Notice, so it can end up in the next 13.0-pX drop?
(In reply to Dimitry Andric from comment #6) Yes, I think it is an errata candidate.
I've submitted a request for an EN, with the template mostly filled in, and a diff. markj@ said it was queued for the next patch run.
A commit in branch releng/13.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dac086497e50619b26d227de02b602f5350d7366 commit dac086497e50619b26d227de02b602f5350d7366 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-06-03 18:53:18 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-06-29 17:08:58 +0000 Add C++ headers <barrier> <concepts> <execution> <latch> <numbers> <semaphore> I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Approved by: so Security: EN-21:18.libc++ Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days (cherry picked from commit 95aa617e4bf09fcc813b1bab3d0dbf4b606807b1) (cherry picked from commit 70e13c4cffd5ff7a70296bc5c4c3b7525c278b1d) lib/libc++/Makefile | 6 +++++ tools/build/mk/OptionalObsoleteFiles.inc | 43 ++++++++++++++++++++------------ 2 files changed, 33 insertions(+), 16 deletions(-)
This will be in 13.0-p3, should be out in the next few hours.
*** Bug 259220 has been marked as a duplicate of this bug. ***
^Triage: - Re-open pending question about what to do re stable/12, reported as bug 259220 (duped to this issue) - Set mfc-* flags to current state (stable/11 is EoL and will not receive an MFC) - Assign to committer that resolved, pending feedback on stable/12
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=761122c601e849229191a097a5741eda3ab1edb4 commit 761122c601e849229191a097a5741eda3ab1edb4 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-06-03 18:53:18 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-12-25 11:51:01 +0000 Add C++ headers <barrier> <concepts> <execution> <latch> <numbers> <semaphore> I missed adding these to the libc++ Makefile, when importing llvm-project 11.0.0-rc1, even though they were supplied by upstream. While here, update OptionalObsoleteFiles.inc to add these new headers, and cleanup old cruft. Reported by: yuri Submitted by: jkim (Makefile diff) PR: 255374 MFC after: 3 days (cherry picked from commit 95aa617e4bf09fcc813b1bab3d0dbf4b606807b1) lib/libc++/Makefile | 6 +++++ tools/build/mk/OptionalObsoleteFiles.inc | 43 ++++++++++++++++++++------------ 2 files changed, 33 insertions(+), 16 deletions(-)
Does LLVM maintain a list of missing C++ features? Are all available features merged into the FreeBSD repository? What about std::format and std::vformat?
(In reply to Yuri Victorovich from comment #14) > Does LLVM maintain a list of missing C++ features? For libc++, there are these lists (from https://libcxx.llvm.org//index.html#c-dialect-support): * https://libcxx.llvm.org/Status/Cxx14.html (complete) * https://libcxx.llvm.org//Status/Cxx17.html (in progress) * https://libcxx.llvm.org//Status/Cxx20.html (in progress) * https://libcxx.llvm.org//Status/Cxx2b.html (in progress) Typically, libc++ requires the same llvm/clang version to build, but you can often get away with a one or two year old version. > Are all available features merged into the FreeBSD repository? I attempt to merge clang/libc++ (actually llvm-project) release versions after they have been tested with an exp-run. While I don't merge *everything* under llvm-project, I always include complete copies of clang and libc++. > What about std::format and std::vformat? libc++ 13.0 started with some incomplete support, which had to be turned on via LIBCXX_ENABLE_INCOMPLETE_FEATURES, but we didn't use it. libc++ 14.0 has some improvements, but it is not finished: "There’s support for the C++20 header <format>. Some parts are still missing, most notably the compile-time format string validation. Some functions are known to be inefficient, both in memory usage and performance. The implementation isn’t API- or ABI-stable and therefore considered experimental. (Some not-yet-implemented papers require an API-break.) As a result, it is disabled by default, however vendors can enable the header by using -DLIBCXX_ENABLE_INCOMPLETE_FEATURES=ON when configuring their build." I'm unsure if there are any promises to have these features completely finished for libc++ 15.0.
If I remember correctly this PR can be closed now, as 12.4 has a new enough LLVM built-in and support for 12.3 was removed from the Ports Tree today.
(In reply to Rene Ladan from comment #16) Well, this submittal was not done case by case but for C++20 overall. That leads to issues like std::source_location, which https://libcxx.llvm.org//Status/Cxx20.html lists as covered by llvm16's libc++ : P1208R6 LWG Adopt source_location for C++20 Cologne Complete 16.0 That "16.0" is the "First released version" column's content. (I've not reviewed the full list. I just happened to remember the "not there yet" status of this one from looking into its status a while back. If I remember right, there are other areas still classified as "experimental" in llvm15's libc++ but I've have to look up any details.)
A somewhat better reference for the libc++ status is to look at what is linked under: https://libcxx.llvm.org//Status/ in that it has explicit, more-detailed pages referenced for things like Format, Parallelism, Ranges, the Spaceship operator use/support, and Zip --not just the overall C++14/17/20/2b library status that is not detailed about these specific subareas: [TXT] Cxx2b.html 2023-03-23 10:34 164K [TXT] Cxx14.html 2023-01-05 12:31 48K [TXT] Cxx17.html 2023-01-05 12:31 123K [TXT] Cxx20.html 2023-03-07 10:37 170K [TXT] Format.html 2023-03-16 21:34 26K [TXT] Parallelism.html 2023-03-16 21:34 8.2K [TXT] Ranges.html 2023-03-16 21:34 16K [TXT] Spaceship.html 2023-04-01 00:26 34K [TXT] Zip.html 2023-01-05 12:31 13K (Zip is from after C++20. Ranges is a mix of C++20 and later. Parallelism is C++20 but has nothing indicated as completed. Spaceship is C++20 and has a mix of status's. Format is another mix of 20 and later.)
(In reply to Mark Millard from comment #18) Hmm. Parallelism is apparently C++17&20, not just C++20, yet has the llvm status of in-progress or not-started depending on the specific sub-areas referenced: no sub-area indicated as completed. The steps of progress are not in units of overall language/library official-definition versions. Library coverage for C++17 is still somewhat incomplete, despite various parts of the library coverage of C++20 and later being in place in the likes of llvm 16 (say). As for FreeBSD, there is also the timing of when FreeBSD adopts some libc++ material once it is available in a llvm that FreeBSD has partially adopted. This can be later than the language update. (I'm not just referencing holding llvm at the version intended for an upcoming stable branch creation/update until after the change to stable has happened.) So, if there was an overall C++17 libc++ bugzilla submittal analogous to this one, it too would still be "In Progress" in 2023-Apr.
(In reply to Mark Millard from comment #19) I took a stab at trying to use the __cpp_lib_... library feature test macros for -std=c++20 for the FreeBSD system clang++ (c++) vs. modern definitions. The lines with "------" mean that no definition was present. To the right is is the modern year/month date for the most recent change in the value for the feature test macro in question just based on the standards. Sometimes there are multiple comparisons points from the standard versions noted via separate lines. Unfortunately, it is not always obvious if a "(C++23)" line had some prior language standard definition as well: the multiple comparison points are likely rather incomplete. Also, this is subject to errors in the reference material that I used: I've not validated that material. The "(DR)" lines are for where the standards folks fixed definitions with the intent of updating the earlier mistake, and so were not just making a new definition for a new standard: retroactive. Again, completeness may be an issue. The differences I got vs modern were: __cpp_lib_adaptor_iterator_pair_constructor ------ 202106 (C++23) __cpp_lib_algorithm_iterator_requirements ------ 202207 (C++23) __cpp_lib_allocate_at_least ------ 202106 (C++23) __cpp_lib_associative_heterogeneous_erasure ------ 202110 (C++23) __cpp_lib_atomic_float ------ 201711 (C++20) __cpp_lib_atomic_ref ------ 201806 (C++20) __cpp_lib_atomic_shared_ptr ------ 201711 (C++20) __cpp_lib_bind_back ------ 202202 (C++23) __cpp_lib_bitops ------ 201907 (C++20) __cpp_lib_byteswap ------ 202110 (C++23) __cpp_lib_chrono 201611 201907 (C++20) __cpp_lib_concepts 202002 202207 (C++23) __cpp_lib_constexpr_bitset ------ 202207 (C++23) __cpp_lib_constexpr_charconv ------ 202207 (C++23) __cpp_lib_constexpr_cmath ------ 202202 (C++23) __cpp_lib_constexpr_complex ------ 201711 (C++20) __cpp_lib_constexpr_memory 201811 202202 (C++23) __cpp_lib_constexpr_typeinfo ------ 202106 (C++23) __cpp_lib_constexpr_vector ------ 201907 (C++20) __cpp_lib_containers_ranges ------ 202202 (C++23) __cpp_lib_execution ------ 201603 (C++17) __cpp_lib_execution ------ 201902 (C++20) __cpp_lib_expected ------ 202202 (C++23) __cpp_lib_expected ------ 202211 (C++23) __cpp_lib_find_last ------ 202207 (C++23) __cpp_lib_flat_map ------ 202207 (C++23) __cpp_lib_flat_set ------ 202207 (C++23) __cpp_lib_format ------ 201907 (C++20) __cpp_lib_format ------ 202106 (C++20) (DR) __cpp_lib_format ------ 202110 (C++20) (DR) __cpp_lib_format ------ 202207 (C++23) __cpp_lib_format_ranges ------ 202207 (C++23) __cpp_lib_forward_like ------ 202207 (C++23) __cpp_lib_generator ------ 202207 (C++23) __cpp_lib_hardware_interference_size ------ 201703 (C++17) __cpp_lib_invoke_r ------ 202106 (C++23) __cpp_lib_ios_noreplace ------ 202207 (C++23) __cpp_lib_is_implicit_lifetime ------ 202302 (C++23) __cpp_lib_is_layout_compatible ------ 201907 (C++20) __cpp_lib_is_pointer_interconvertible ------ 201907 (C++20) __cpp_lib_is_scoped_enum ------ 202011 (C++23) __cpp_lib_jthread ------ 201911 (C++20) __cpp_lib_math_special_functions ------ 201603 (C++17) __cpp_lib_mdspan ------ 202207 (C++23) __cpp_lib_memory_resource ------ 201603 (C++17) __cpp_lib_modules ------ 202207 (C++23) __cpp_lib_move_iterator_concept ------ 202207 (C++23) __cpp_lib_move_only_function ------ 202110 (C++23) __cpp_lib_optional 201606 202106 (C++20) (DR) __cpp_lib_optional 201606 202110 (C++23) __cpp_lib_out_ptr ------ 202106 (C++23) __cpp_lib_parallel_algorithm ------ 201603 (C++17) __cpp_lib_polymorphic_allocator ------ 201902 (C++20) __cpp_lib_print ------ 202207 (C++23) __cpp_lib_ranges ------ 201911 (C++20) __cpp_lib_ranges ------ 202106 (C++20) (DR) __cpp_lib_ranges ------ 202110 (C++20) (DR) __cpp_lib_ranges ------ 202202 (C++23) __cpp_lib_ranges ------ 202207 (C++23) __cpp_lib_ranges ------ 202211 (C++23) __cpp_lib_ranges_as_const ------ 202207 (C++23) __cpp_lib_ranges_as_rvalue ------ 202207 (C++23) __cpp_lib_ranges_cartesian_product ------ 202207 (C++23) __cpp_lib_ranges_chunk ------ 202202 (C++23) __cpp_lib_ranges_chunk_by ------ 202202 (C++23) __cpp_lib_ranges_contains ------ 202207 (C++23) __cpp_lib_ranges_enumerate ------ 202303 (C++23) __cpp_lib_ranges_fold ------ 202207 (C++23) __cpp_lib_ranges_iota ------ 202202 (C++23) __cpp_lib_ranges_join_with ------ 202202 (C++23) __cpp_lib_ranges_repeat ------ 202207 (C++23) __cpp_lib_ranges_slide ------ 202202 (C++23) __cpp_lib_ranges_starts_ends_with ------ 202106 (C++23) __cpp_lib_ranges_stride ------ 202207 (C++23) __cpp_lib_ranges_to_container ------ 202202 (C++23) __cpp_lib_ranges_zip ------ 202110 (C++23) __cpp_lib_reference_from_temporary ------ 202202 (C++23) __cpp_lib_shift 201806 202202 (C++23) __cpp_lib_smart_ptr_for_overwrite ------ 202002 (C++20) __cpp_lib_source_location ------ 201907 (C++20) __cpp_lib_spanstream ------ 202106 (C++23) __cpp_lib_stacktrace ------ 202011 (C++23) __cpp_lib_start_lifetime_as ------ 202207 (C++23) __cpp_lib_stdatomic_h ------ 202011 (C++23) __cpp_lib_string_contains ------ 202011 (C++23) __cpp_lib_string_resize_and_overwrite ------ 202110 (C++23) __cpp_lib_syncbuf ------ 201803 (C++20) __cpp_lib_three_way_comparison ------ 201907 (C++20) __cpp_lib_to_chars ------ 201611 (C++17) __cpp_lib_to_underlying ------ 202102 (C++23) __cpp_lib_tuple_like ------ 202207 (C++23) __cpp_lib_unreachable ------ 202202 (C++23) __cpp_lib_variant 202102 202106 (C++20) (DR) This was for: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 I will note that the results for the likes of devel/llvm16 are the same because of the implicit use of the system's libc++ .
(In reply to Mark Millard from comment #20) This list below is much shorter. I found a way to (mostly?) eliminate the part of the list that is really just "since C++23". The macro name list is not identical, unforntuately. I expect that the lines below that do not indicate a "since C++??" are actually "since C++23" but have not verified. I left such lines below for reference. There are some "since C++20" lines below that list modern as being "C++17" with a 2016/2017 year involved. I expect these are really "since C++17", such as for __cpp_lib_to_chars . I again left the oddities for reference since I'm not doing a detailed validation. The below does also have some "updated in C++23" notes. __cpp_lib_atomic_float ------ 201711 (C++20) (since C++20) __cpp_lib_atomic_ref ------ 201806 (C++20) (since C++20) __cpp_lib_atomic_shared_ptr ------ 201711 (C++20) (since C++20) __cpp_lib_bitops ------ 201907 (C++20) (since C++20) __cpp_lib_chrono 201611 201907 (C++20) (since C++20) __cpp_lib_concepts 202002 202207 (C++23) (since C++20)(updated in C++23) __cpp_lib_constexpr_complex ------ 201711 (C++20) (since C++20) __cpp_lib_constexpr_memory 201811 202202 (C++23) (since C++20)(updated in C++23) __cpp_lib_constexpr_vector ------ 201907 (C++20) (since C++20) __cpp_lib_execution ------ 201603 (C++17) (since C++20) __cpp_lib_execution ------ 201902 (C++20) (since C++20) __cpp_lib_format ------ 201907 (C++20) (since C++20)(updated in C++23) __cpp_lib_format ------ 202106 (C++20) (DR) (since C++20)(updated in C++23) __cpp_lib_format ------ 202110 (C++20) (DR) (since C++20)(updated in C++23) __cpp_lib_format ------ 202207 (C++23) (since C++20)(updated in C++23) __cpp_lib_hardware_interference_size ------ 201703 (C++17) (since C++20) __cpp_lib_int_pow2 (since C++20) __cpp_lib_is_implicit_lifetime ------ 202302 (C++23) __cpp_lib_is_layout_compatible ------ 201907 (C++20) (since C++20) __cpp_lib_is_pointer_interconvertible ------ 201907 (C++20) (since C++20) __cpp_lib_jthread ------ 201911 (C++20) (since C++20) __cpp_lib_math_special_functions ------ 201603 (C++17) (since C++20) __cpp_lib_memory_resource ------ 201603 (C++17) (since C++20) __cpp_lib_modules ------ 202207 (C++23) __cpp_lib_optional 201606 202106 (C++20) (DR) (since C++20)(updated in C++23) __cpp_lib_optional 201606 202110 (C++23) (since C++20)(updated in C++23) __cpp_lib_parallel_algorithm ------ 201603 (C++17) (since C++20) __cpp_lib_polymorphic_allocator ------ 201902 (C++20) (since C++20) __cpp_lib_ranges ------ 201911 (C++20) (since C++20)(updated in C++23) __cpp_lib_ranges ------ 202106 (C++20) (DR) (since C++20)(updated in C++23) __cpp_lib_ranges ------ 202110 (C++20) (DR) (since C++20)(updated in C++23) __cpp_lib_ranges ------ 202202 (C++23) (since C++20)(updated in C++23) __cpp_lib_ranges ------ 202207 (C++23) (since C++20)(updated in C++23) __cpp_lib_ranges ------ 202211 (C++23) (since C++20)(updated in C++23) __cpp_lib_ranges_enumerate ------ 202303 (C++23) __cpp_lib_shift 201806 202202 (C++23) (since C++20)(updated in C++23) __cpp_lib_smart_ptr_for_overwrite ------ 202002 (C++20) (since C++20) __cpp_lib_source_location ------ 201907 (C++20) (since C++20) __cpp_lib_syncbuf ------ 201803 (C++20) (since C++20) __cpp_lib_three_way_comparison ------ 201907 (C++20) (since C++20) __cpp_lib_to_chars ------ 201611 (C++17) (since C++20) __cpp_lib_variant 202102 202106 (C++20) (DR) (since C++20)(updated in C++23)
Turns out that opensuse tumblweed can install llvm16 related materials such that -stdlib=libc++ can be used. Based on this it appears that for the llvm16 __cpp_lib_... feature test macros vs. the existing main Freebsd ones: If fully adopted, the libc++ would go from having undefined status to having the modern values for: __cpp_lib_constexpr_complex __cpp_lib_constexpr_vector __cpp_lib_memory_resource __cpp_lib_polymorphic_allocator __cpp_lib_source_location Also, __cpp_lib_ranges would go from undefined to 202106 . C++20 also has a later 202110 . C++23 has 3 later values, the last being 202211 . (I'm generally omitting the L suffixes in my materials.) It does not appear that any other __cpp_lib_... macros would change values. These notes are based on using -std=c++20 . Other notes: __cpp_lib_int_pow2 in my prior note turned out to be from it not being in the sort order position for the join operation in the material that I copied/genrated and processed. It is in fact up to date in main FreeBSD.
Interestingly, 13.2-RELEASE has std::format working (it has clang-14.0.5), but 13.2-STABLE doesn't have std::format working, with llvm-project being at version 15.x So there is a regression.
(In reply to Yuri Victorovich from comment #23) https://libcxx.llvm.org/FeatureTestMacroTable.html#feature-status reports: __cpp_lib_format unimplemented but that is what they show for incomplete or significantly (but partially) incorrect preliminary support. https://libcxx.llvm.org/Status/Format.html reports lots of detailed status with "first released version" for each detail. There are: 4 rows listing clang 14 3 rows listing clang 15 25 rows listing clang 16 9 rows listing clang 17 6 rows listing in progress 12 rows that have the column still blank (if I counted right) The libcxx 17 release notes draft at https://libcxx.llvm.org/ReleaseNotes.html indicates: QUOTE The formatter specialization template<size_t N> struct formatter<const charT[N], charT> has been removed. Since libc++’s format library was marked experimental there is no backwards compatibility option. This specialization has been removed from the Standard since it was never used, the proper specialization to use instead is template<size_t N> struct formatter<charT[N], charT> END QUOTE I've no clue if that is related to what you are reporting. It is hard to tell what specifically changed status that you noticed. So I can not be much more specific. Nor can I check the status in main foor whatever you found.
(In reply to Yuri Victorovich from comment #23) Looking, I see in main [so: 14 with LLVM 15.0.7 materials] : # more /usr/include/c++/v1/format . . . #ifndef _LIBCPP_FORMAT #define _LIBCPP_FORMAT . . . #include <__assert> // all public C++ headers provide the assertion handler // Make sure all feature-test macros are available. #include <version> // Enable the contents of the header only when libc++ was built with experimental features enabled. #if !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT) . . . #endif // !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT) #endif // _LIBCPP_FORMAT
(In reply to Mark Millard from comment #25) I found my copy of 13.2-RELEASE and its header is similar in some respects but it instead has: . . . #ifndef _LIBCPP_FORMAT #define _LIBCPP_FORMAT . . . // Enable the contents of the header only when libc++ was built with LIBCXX_ENABLE_INCOMPLETE_FEATURES. #if !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT) . . . #endif // !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT) #endif // _LIBCPP_FORMAT So it looks like there was a reclassification from it being an incomplete-feature in clang 14 to it being an experimental-feature in clang 15. I do not know if FreeBSD has a uniform handling of experimental-status material in its LLVM. It might be that "incomplete feature" is no longer a thing in LLVM --so I'm not sure if the analogous question would even apply now.
(In reply to Mark Millard from comment #26) Looks like __has_feature(experimental_library) and _LIBCPP_ENABLE_EXPERIMENTAL were new as of LLVM 15. LLVM 14 does not have the analogous overall logic to ( /usr/include/c++/v1/__config ) : . . . # 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 . . . LLVM 14 just has ( /usr/include/c++/v1/__config_site ): /* #undef _LIBCPP_HAS_NO_INCOMPLETE_FORMAT */ /* #undef _LIBCPP_HAS_NO_INCOMPLETE_RANGES */ with no more-overall logic involved.
(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.
(In reply to Yuri Victorovich from comment #23) [Also for Dimitry Andric vs. my original misinterpretation of __has_feature(experimental_library)] Hmm. Looks like -fexperimental-library enables __has_feature(experimental_library) and this is for client code use of an installed libc++ . Have you tried using -fexperimental-library when you test for std::format "working"?
(In reply to Mark Millard from comment #28) [Also for Dimitry Andric vs. my original misinterpretation of __has_feature(experimental_library)] My question in #28 may be incoherent via misinterpreting what controls __has_feature(experimental_library) and when it is relevant . Turns out it seems to be -fexperimental-library use when building client code, if I read the materials correctly.