]> git.ipfire.org Git - thirdparty/gcc.git/commit
libstdc++: Implement C++23 <print> header [PR107760]
authorJonathan Wakely <jwakely@redhat.com>
Thu, 14 Dec 2023 23:23:34 +0000 (23:23 +0000)
committerJonathan Wakely <jwakely@redhat.com>
Thu, 14 Dec 2023 23:59:24 +0000 (23:59 +0000)
commitfe54b57728c09ab0389e2bb3f079d5210566199d
tree1007a2d3e0e8d60906e2a21ae483ef36928f17c1
parent29ad35a1db645f6027acc4f2a9b15363f402ca97
libstdc++: Implement C++23 <print> header [PR107760]

This adds the C++23 std::print functions, which use std::format to write
to a FILE stream or std::ostream (defaulting to stdout).

The new extern symbols are in the libstdc++exp.a archive, so we aren't
committing to stable symbols in the DSO yet. There's a UTF-8 validating
and transcoding function added by this change. That can certainly be
optimized, but it's internal to libstdc++exp.a so can be tweaked later
at leisure.

Currently the external symbols work for all targets, but are only
actually used for Windows, where it's necessary to transcode to UTF-16
to write to the console.  The standard seems to encourage us to also
diagnose invalid UTF-8 for non-Windows targets when writing to a
terminal (and only when writing to a terminal), but I'm reliably
informed that that wasn't the intent of the wording. Checking for
invalid UTF-8 sequences only needs to happen for Windows, which is good
as checking for a terminal requires a call to isatty, and on Linux that
uses an ioctl syscall, which would make std::print ten times slower!

Testing the std::print behaviour is difficult if it depends on whether
the output stream is connected to a Windows console or not, as we can't
(as far as I know) do that non-interactively in DejaGNU. One of the new
tests uses the internal __write_to_terminal function directly. That
allows us to verify its UTF-8 error handling on POSIX targets, even
though that's not actually used by std::print. For Windows, that
__write_to_terminal function transcodes to UTF-16 but then uses
WriteConsoleW which fails unless it really is writing to the console.
That means the 27_io/print/2.cc test FAILs on Windows. The UTF-16
transcoding has been manually tested using mingw-w64 and Wine, and
appears to work.

libstdc++-v3/ChangeLog:

PR libstdc++/107760
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/version.def (__cpp_lib_print): Define.
* include/bits/version.h: Regenerate.
* include/std/format (__literal_encoding_is_utf8): New function.
(_Seq_sink::view()): New member function.
* include/std/ostream (vprintf_nonunicode, vprintf_unicode)
(print, println): New functions.
* include/std/print: New file.
* src/c++23/Makefile.am: Add new source file.
* src/c++23/Makefile.in: Regenerate.
* src/c++23/print.cc: New file.
* testsuite/27_io/basic_ostream/print/1.cc: New test.
* testsuite/27_io/print/1.cc: New test.
* testsuite/27_io/print/2.cc: New test.
13 files changed:
libstdc++-v3/include/Makefile.am
libstdc++-v3/include/Makefile.in
libstdc++-v3/include/bits/version.def
libstdc++-v3/include/bits/version.h
libstdc++-v3/include/std/format
libstdc++-v3/include/std/ostream
libstdc++-v3/include/std/print [new file with mode: 0644]
libstdc++-v3/src/c++23/Makefile.am
libstdc++-v3/src/c++23/Makefile.in
libstdc++-v3/src/c++23/print.cc [new file with mode: 0644]
libstdc++-v3/testsuite/27_io/basic_ostream/print/1.cc [new file with mode: 0644]
libstdc++-v3/testsuite/27_io/print/1.cc [new file with mode: 0644]
libstdc++-v3/testsuite/27_io/print/2.cc [new file with mode: 0644]