Bug 255374 - C++20 features (headers) std::concepts, std::format, std::numbers, std::source_location, etc. are missing
Summary: C++20 features (headers) std::concepts, std::format, std::numbers, std::sourc...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Dimitry Andric
URL:
Keywords:
: 259220 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-04-24 20:39 UTC by Yuri Victorovich
Modified: 2024-05-05 19:29 UTC (History)
8 users (show)

See Also:
koobs: maintainer-feedback? (dim)
koobs: mfc-stable13+
koobs: mfc-stable12?
koobs: mfc-stable11-


Attachments
Install new C++ header files (1.34 KB, patch)
2021-06-03 06:05 UTC, Jung-uk Kim
jkim: maintainer-approval? (dim)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2021-04-24 20:39:43 UTC
See https://en.cppreference.com/w/cpp/utility/format/format
Comment 1 Yuri Victorovich freebsd_committer freebsd_triage 2021-05-13 01:10:28 UTC
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?
Comment 2 Dimitry Andric freebsd_committer freebsd_triage 2021-05-19 17:16:07 UTC
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.
Comment 3 Jung-uk Kim freebsd_committer freebsd_triage 2021-06-03 06:05:33 UTC
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.
Comment 4 commit-hook freebsd_committer freebsd_triage 2021-06-03 18:54:08 UTC
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(-)
Comment 5 commit-hook freebsd_committer freebsd_triage 2021-06-06 11:51:23 UTC
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(-)
Comment 6 Dimitry Andric freebsd_committer freebsd_triage 2021-06-06 11:59:08 UTC
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?
Comment 7 Jung-uk Kim freebsd_committer freebsd_triage 2021-06-07 13:34:14 UTC
(In reply to Dimitry Andric from comment #6)
Yes, I think it is an errata candidate.
Comment 8 Dimitry Andric freebsd_committer freebsd_triage 2021-06-13 19:12:21 UTC
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.
Comment 9 commit-hook freebsd_committer freebsd_triage 2021-06-29 20:24:24 UTC
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(-)
Comment 10 Mark Johnston freebsd_committer freebsd_triage 2021-06-29 20:35:09 UTC
This will be in 13.0-p3, should be out in the next few hours.
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-17 03:16:43 UTC
*** Bug 259220 has been marked as a duplicate of this bug. ***
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-17 03:19:12 UTC
^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
Comment 13 commit-hook freebsd_committer freebsd_triage 2021-12-25 11:58:34 UTC
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(-)
Comment 14 Yuri Victorovich freebsd_committer freebsd_triage 2022-07-17 18:07:14 UTC
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?
Comment 15 Dimitry Andric freebsd_committer freebsd_triage 2022-07-17 18:30:39 UTC
(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.
Comment 16 Rene Ladan freebsd_committer freebsd_triage 2023-03-31 07:10:45 UTC
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.
Comment 17 Mark Millard 2023-03-31 08:18:03 UTC
(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.)
Comment 18 Mark Millard 2023-04-02 20:08:05 UTC
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.)
Comment 19 Mark Millard 2023-04-02 20:46:29 UTC
(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.
Comment 20 Mark Millard 2023-04-03 22:18:01 UTC
(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++ .
Comment 21 Mark Millard 2023-04-04 01:36:39 UTC
(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)
Comment 22 Mark Millard 2023-04-05 16:54:55 UTC
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.
Comment 23 Yuri Victorovich freebsd_committer freebsd_triage 2023-05-17 04:48:54 UTC
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.
Comment 24 Mark Millard 2023-05-17 06:28:35 UTC
(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.
Comment 25 Mark Millard 2023-05-17 06:55:44 UTC
(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
Comment 26 Mark Millard 2023-05-17 07:12:34 UTC
(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.
Comment 27 Mark Millard 2023-05-17 07:39:26 UTC
(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.
Comment 28 Mark Millard 2023-05-21 22:17:15 UTC
(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.
Comment 29 Mark Millard 2023-05-22 01:55:28 UTC
(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"?
Comment 30 Mark Millard 2023-05-22 02:00:30 UTC
(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.
Comment 31 Mark Millard 2023-06-10 04:10:38 UTC
(In reply to Mark Millard from comment #29 and #30)

https://lists.freebsd.org/archives/freebsd-standards/2023-June/000502.html

from/for: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271931

and is about using -fexperimental-library to enable use of std::ranges:copy .
It did enable such use.

Other examples of reports of features being missing may well find
some of them available if -fexperimental-library had not been used
but is added to the compile's command line.
Comment 32 Mark Millard 2023-06-11 19:36:27 UTC
I will note that for LLVM16 there will still be in
/usr/include/c++/v1/__config the likes of (from
openSUSE tumbleweed libc++ installation):

. . .
#ifdef __cplusplus

// _LIBCPP_VERSION represents the version of libc++, which matches the version of LLVM.
// Given a LLVM release LLVM XX.YY.ZZ (e.g. LLVM 16.0.1 == 16.00.01), _LIBCPP_VERSION is
// defined to XXYYZZ.
#  define _LIBCPP_VERSION 160002
. . .
#  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
#  endif
. . .

which will make -fexperimental-library required in order to
have C++20's std::format generally enabled: still considered
experimental in LLVM16.
Comment 33 Dimitry Andric freebsd_committer freebsd_triage 2024-05-05 19:29:42 UTC
With the recent clang and libc++ 18 import, we now have:

<concepts>
<format>
<numbers>
<source_location>

This has also been MFC'd to stable/14 and stable/13, so all supported branches now have them.