https://bugs.llvm.org/show_bug.cgi?id=49241
Bug ID: 49241
Summary: std::to_address should not require
std::pointer_traits<Pointer>::element_type to be
well-formed
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: scho...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Per [pointer.conversion] ¶ 3 (http://eel.is/c++draft/pointer.conversion#3), if
the argument to std::to_address matches the overload for const Pointer&, it
uses std::pointer_traits<Pointer>::to_address(p) if that is well-formed,
otherwise to_address(p.operator->()).
Nowhere does it say that std::pointer_traits<Pointer> has to exist at all in
the case where operator->() is chosen. However, in __memory/pointer_traits.h[1]
we see that the return type is dictated as
std::pointer_traits<Pointer>::element_type* despite the fact that there are
many types in the wild that overload operator-> and *should* be expected to
work with std::to_address, but don't.
See [2] for an example of a type that should work per the standard but doesn't
unless we define std::pointer_traits<Pointer>::element_type. (It appears that
godbolt uses libstdc++ even when you select clang, but from my own local
testing [and inspection of libc++'s implementation], I've determined that
libc++ has the same problem.)
It looks like the original implementation in [3] was fine (unless you were on
C++17) but it was broken in [4] when __to_raw_pointer and __to_address were
merged. It seems that priority was given to using __to_address() as an internal
function, and this existing usage clashed with the public std::to_address in
non-obvious ways.
[1]:
https://github.com/llvm/llvm-project/blob/da59c2e4dc1c7b502cc2098247b2ee38ac297e0c/libcxx/include/__memory/pointer_traits.h#L199
[2]: https://godbolt.org/z/47cxTG
[3]: https://reviews.llvm.org/D35470
[4]: https://reviews.llvm.org/rG0068c5913999b14627c27433c8d846a2ef5fbe00
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
