From: Jonathan Wakely <jwakely@redhat.com>
To: Christophe Lyon <christophe.lyon@linaro.org>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>,
gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [committed] libstdc++: Fix filesystem::path comparisons for C++23
Date: Mon, 14 Jun 2021 15:19:55 +0100 [thread overview]
Message-ID: <CACb0b4nLdTyENuzeQV1aDrT7xyLqrSbnMX6evmCh2=NJQjxH-Q@mail.gmail.com> (raw)
In-Reply-To: <CAKdteObxa9o-X-xeBOnuU=5j6eO4DeGACRoHFnC7yL-jujwBHg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
On Mon, 14 Jun 2021 at 13:58, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
>
> Hi Jonathan,
>
> On Fri, 11 Jun 2021 at 20:25, Jonathan Wakely via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > In C++23 there is a basic_string_view(Range&&) constructor, which is
> > constrained to take a range (specifically, a contiguous_range). When the
> > filesystem::path comparison operators call lhs.compare(rhs) the overload
> > taking a string_view is considered, which means checking whether path
> > satisfies the range concept. That satisfaction result changes depending
> > whether path::iterator is complete, which is ill-formed; no diagnostic
> > required. To avoid the problem, this change ensures that the overload
> > resolution is performed in a context where path::iterator is complete
> > and the range concept is satisfied. (The result of overload resolution
> > is always that the compare(const path&) overload is the best match, but
> > we still have to consider the compare(basic_string_view<value_type>) one
> > to decide if it even participates in overload resolution).
> >
> > For std::filesystem::path we can't define the comparison operators later
> > in the file, because they are hidden friends, so a new helper is
> > introduced that gets defined when everything else is complete.
> >
> > For std::experimental::filesystem::path we can just move the definitions
> > of the comparison operators later in the file.
> >
> > Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/fs_path.h (operator==, operator<=>): Use new
> > _S_compare function.
> > (path::_S_compare): New function to call path::compare in a
> > context where path::iterator is complete.
> > * include/experimental/bits/fs_path.h (operator<, operator==):
> > Define after path::iterator is complete.
> > * testsuite/27_io/filesystem/path/native/conv_c++23.cc: New
> > test.
> > * testsuite/experimental/filesystem/path/native/conv_c++23.cc:
> > New test.
> >
> > Tested powerpc64le-linux. Committed to trunk.
> >
> > This also needs to be backported to gcc-11 where the string_view
> > constructor is present for C++23 mode.
> >
>
> The new test experimental/filesystem/path/native/conv_c++23.cc
> fails on arm-eabi and aarch64-elf:
> /libstdc++-v3/testsuite/experimental/filesystem/path/native/conv_c++23.cc:4:
> fatal error: experimental/filesystem: No such file or directory
> (both trunk and gcc-11)
>
> I guess that's easy to fix? :-)
Yes, fixed on trunk now by the attached patch. Tests running for the
gcc-11 backport.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 871 bytes --]
commit a40d2293a7a417fc7711f8f4e52dbd4c48c2a43f
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Jun 14 14:22:07 2021
libstdc++: Only run Filesystem TS test if supported
libstdc++-v3/ChangeLog:
* testsuite/experimental/filesystem/path/native/conv_c++23.cc:
Add dg-require-filesystem-ts directive.
diff --git a/libstdc++-v3/testsuite/experimental/filesystem/path/native/conv_c++23.cc b/libstdc++-v3/testsuite/experimental/filesystem/path/native/conv_c++23.cc
index f3c3f884965..81f57549ac9 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/path/native/conv_c++23.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/path/native/conv_c++23.cc
@@ -1,5 +1,6 @@
// { dg-options "-std=gnu++23" }
// { dg-do compile { target c++23 } }
+// { dg-require-filesystem-ts "" }
#include <experimental/filesystem>
prev parent reply other threads:[~2021-06-14 14:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 18:24 Jonathan Wakely
2021-06-14 12:58 ` Christophe Lyon
2021-06-14 14:19 ` Jonathan Wakely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACb0b4nLdTyENuzeQV1aDrT7xyLqrSbnMX6evmCh2=NJQjxH-Q@mail.gmail.com' \
--to=jwakely@redhat.com \
--cc=christophe.lyon@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).