[PATCH] C++ P0482R6 char8_t: declare std::c8rtomb and std::mbrtoc8 if provided by the C library

[Tom Honermann]

On 1/10/22 4:38 PM, Jonathan Wakely wrote:
> On Mon, 10 Jan 2022 at 21:24, Tom Honermann via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
>> On 1/10/22 8:23 AM, Jonathan Wakely wrote:
>>>
>>> On Sat, 8 Jan 2022 at 00:42, Tom Honermann via Libstdc++
>>> <libstdc++@gcc.gnu.org <mailto:libstdc%2B%2B@gcc.gnu.org>> wrote:
>>>
>>>      This patch completes implementation of the C++20 proposal P0482R6
>>>      [1] by
>>>      adding declarations of std::c8rtomb() and std::mbrtoc8() in
>>>      <cuchar> if
>>>      provided by the C library in <uchar.h>.
>>>
>>>      This patch addresses feedback provided in response to a previous
>>>      patch
>>>      submission [2].
>>>
>>>      Autoconf changes determine if the C library declares c8rtomb and
>>>      mbrtoc8
>>>      at global scope when uchar.h is included and compiled with either
>>>      -fchar8_t or -std=c++20. New
>>>      _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T
>>>      and _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 configuration macros
>>>      reflect the probe results. The <cuchar> header declares these
>>>      functions
>>>      in the std namespace only if available and the _GLIBCXX_USE_CHAR8_T
>>>      configuration macro is defined (by default it is defined if the C++20
>>>      __cpp_char8_t feature test macro is defined)
>>>
>>>      Patches to glibc to implement c8rtomb and mbrtoc8 have been
>>>      submitted [3].
>>>
>>>      New tests validate the presence of these declarations. The tests pass
>>>      trivially if the C library does not provide these functions.
>>>      Otherwise
>>>      they ensure that the functions are declared when <cuchar> is included
>>>      and either -fchar8_t or -std=c++20 is enabled.
>>>
>>>      Tested on Linux x86_64.
>>>
>>>      libstdc++-v3/ChangeLog:
>>>
>>>      2022-01-07  Tom Honermann  <tom@honermann.net
>>>      <mailto:tom@honermann.net>>
>>>
>>>              * acinclude.m4 Define config macros if uchar.h provides
>>>              c8rtomb() and mbrtoc8().
>>>              * config.h.in <http://config.h.in>: Re-generate.
>>>              * configure: Re-generate.
>>>              * include/c_compatibility/uchar.h: Declare ::c8rtomb and
>>>              ::mbrtoc8.
>>>              * include/c_global/cuchar: Declare std::c8rtomb and
>>>              std::mbrtoc8.
>>>              * include/c_std/cuchar: Declare std::c8rtomb and std::mbrtoc8.
>>>              * testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
>>>              New test.
>>>              *
>>>      testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
>>>              New test.
>>>
>>>
>>>
>>> Thanks, Tom, this looks good and I'll get it committed for GCC 12.
>> Thank you!
>>> My only concern is that the new tests depend on an internal macro:
>>>
>>> +#if _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20
>>> +  using std::mbrtoc8;
>>> +  using std::c8rtomb;
>>>
>>> I prefer if tests are written as "user code" when possible, and not
>>> using our internal macros. That isn't always possible, and in this
>>> case would require adding new effective-target keyword to
>>> testsuite/lib/libstdc++.exp just for use in these two tests. I don't
>>> think we should bother with that.
>> I went with this approach solely due to my unfamiliarity with the test
>> system. I knew there should be a way to conditionally make the test
>> "pass" as unsupported or as an expected failure, but didn't know how to
>> go about implementing that. I don't mind following up with an additional
>> patch if such a change is desirable. I took a look at
>> testsuite/lib/libstdc++.exp and it looks like it may be pretty straight
>> forward to add effective-target support. It would probably be a good
>> learning experience for me. I'll prototype and report back.
> Yes, it's very easy to do. Take a look at the
> check_effective_target_blah procs in that file, especially the later
> ones that use v3_check_preprocessor_condition. You can use that to
> define an effective target keyword for any preprocessor condition
> (such as the new macros you're adding).
>
> Then the test can do:
> // { dg-do compile { target blah } }
> which will make it UNSUPPORTED if the effective target proc doesn't return true.
> See https://gcc.gnu.org/onlinedocs/gccint/Selectors.html#Selectors for
> the docs on target selectors.
>
> I'm just not sure it's worth adding a new keyword for just two tests.

Thank you for the implementation direction; this was quite easy!

Patch attached (to be applied after the original one).

libstdc++-v3/ChangeLog:

2022-01-11  Tom Honermann  <tom@honermann.net>

	* testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
	Modify to use new c8rtomb_mbrtoc8_cxx20 effective target.
	* testsuite/21_strings/headers/cuchar/functions_std_fchar8_t.cc:
	Modify to use new c8rtomb_mbrtoc8_fchar8_t effective target.
	* testsuite/lib/libstdc++.exp: Add new effective targets.

If you decide that the new keywords aren't worth adding, no worries; my 
feelings won't be hurt :)

Tom.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: p0482r6-n2653-eff-target.patch
Type: text/x-patch
Size: 2648 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20220111/5b26cf9f/attachment-0001.bin>