[libcxx-commits] [PATCH] D113161: [libc++] Implement P1989R2: range constructor for string_view
Joe Loser via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Sun Nov 21 16:30:29 PST 2021
jloser added a comment.
In D113161#3145181 <https://reviews.llvm.org/D113161#3145181>, @Quuxplusone wrote:
> @jloser: Found it! You need to do this in `<filesystem>`:
>
> friend _LIBCPP_INLINE_VISIBILITY bool operator==(const path& __lhs, const path& __rhs) noexcept {
> - return __lhs.compare(__rhs) == 0;
> + return __lhs.__compare(__rhs.__pn_) == 0;
> }
>
> (and likewise for each of `path`'s six comparison operators).
> The problem is that instantiating `path` instantiates `operator==`, which triggers overload resolution on `__lhs.compare(__rhs)`, which evaluates whether `__rhs` can be converted to `string_view`... and at that point, it //cannot// (because its iterator type is still incomplete at that point). So, it goes boom. The hack-around is to make sure we don't call anything that might ever try to convert `path` to `string_view` before its time.
Ah! That makes total sense. I think the thing that threw me off is the `const`ness of the problem. It works fine for `path` but not `const path` because of the const-qualified-ness of the `compare` functions, right?
I just pushed a fix with these `path` operator changes - let's see what CI thinks. I still need to test locally with llvm + this patched libc++ to see whether we have compile errors in the mentioned bug.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113161/new/
https://reviews.llvm.org/D113161
More information about the libcxx-commits
mailing list