Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]

On May 3, 2023, at 08:57, Mark Millard <marklmi@yahoo.com> wrote:

> Alexey Dokuchaev <danfe_at_freebsd.org> wrote on
> Date: Wed, 03 May 2023 07:53:09 UTC :
> 
>> On Mon, May 01, 2023 at 06:14:49PM +0000, Glen Barber wrote:
>>> ...
>>> There is no feasible way we are going to make the branch point of
>>> stable/14 in time, with that scheduled for May 12, 2023 with the above
>>> points. That said, this is not an all-inclusive list, but the more
>>> major items on our radar at the moment.
>> 
>> Does this delay mean we might get Clang 16 in the base? Current 15.0.7
>> hits assertion on one of my ports which had allegedly been fixed in 16.
>> Also, AFAIU it comes with better support for modern C++, e.g. ranges.
> 
> These notes are based on using -std=c++20 and llvm16 on
> opensuse tumblweed (in early April), which has libc++
> support configurable. They also presume that the FreeBSD
> llvm16 update fully adopts the libc++ from llvm16.
> (FreeBSD LLVM upgrades do not always do so at the initial
> upgrade time.)
> 
> __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.)
> 
> A couple of the C++20 ranges versions are late,
> retroactive fixes ["(DR)"s] for things that
> could not wait for C++23:
> 
> __cpp_lib_ranges ------ 202106 (C++20) (DR)
> __cpp_lib_ranges ------ 202110 (C++20) (DR)
> 
> So only the 202106 one was in llvm16 when I tested
> llvm16. (If I remember right, using -std=c++23 got
> the 202110 fix as well.)
> 
> Other libc++ things going from undefined to a defined
> status are:
> 
> __cpp_lib_constexpr_complex
> __cpp_lib_constexpr_vector
> __cpp_lib_memory_resource
> __cpp_lib_polymorphic_allocator
> __cpp_lib_source_location
> 
> It does not appear that any other __cpp_lib_... macros
> would change values for -std=c+=20 use.

Typo fix to the above: -std=c++20

> As for the overall status for ranges . . .
> 
> C++23 has lots of changes/additions for ranges:
> (The ------'s indicate being undefined in llvm15.)

I should have noted that the YYYYMM months
below are from/for the standard and are not
indications of llvm16 or later of having
implemented them for -std=c+=23 .

> __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)
> 
> Ranges seems to be an active area of development
> across multiple standard vintages.


===
Mark Millard
marklmi at yahoo.com