| Message ID | CAFk2RUY+car5uBT5o-sAJEGrPtWWJKXqcUs7MN=BQfJ3ysTj1A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 7 February 2017 at 22:00, Ville Voutilainen <ville.voutilainen@gmail.com> wrote: > Currently, clang rejects all attempts to visit a libstdc++ variant: > https://godbolt.org/g/kSmBTg > > While gcc doesn't reject such code, that seems like an access checking > bug. This patch makes the offending _M_u member accessible for the rest > of the code. Hmh. There's already a friend declaration for the functions that supposedly need it. clang doesn't seem to grok that friend declaration. gcc requires that friend declaration, so perhaps the bug is indeed in how clang handles friend templates.
On 07/02/17 23:29 +0200, Ville Voutilainen wrote: >On 7 February 2017 at 22:00, Ville Voutilainen ><ville.voutilainen@gmail.com> wrote: >> Currently, clang rejects all attempts to visit a libstdc++ variant: >> https://godbolt.org/g/kSmBTg >> >> While gcc doesn't reject such code, that seems like an access checking >> bug. This patch makes the offending _M_u member accessible for the rest >> of the code. > > >Hmh. There's already a friend declaration for the functions that >supposedly need it. clang doesn't >seem to grok that friend declaration. gcc requires that friend >declaration, so perhaps the bug >is indeed in how clang handles friend templates. Definitely a clang bug, see http://melpon.org/wandbox/permlink/PkbNSpvjPrLh8rov If we remove the nested namespace we see that the friend declaration is declaring a second, unrelated function, and so we get an ambiguity: http://melpon.org/wandbox/permlink/wvmzgAzpLp5pOf86
On 08/02/17 13:56 +0000, Jonathan Wakely wrote: >Definitely a clang bug, see >http://melpon.org/wandbox/permlink/PkbNSpvjPrLh8rov > >If we remove the nested namespace we see that the friend declaration >is declaring a second, unrelated function, and so we get an ambiguity: >http://melpon.org/wandbox/permlink/wvmzgAzpLp5pOf86 It's https://llvm.org/bugs/show_bug.cgi?id=31852
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index c5138e5..54e8b67 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -957,6 +957,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __detail::__variant::__index_of_v<_Tp, _Types...>; public: + using _Base::_M_u; constexpr variant() noexcept(is_nothrow_default_constructible_v<__to_type<0>>) = default; variant(const variant&) = default;
Currently, clang rejects all attempts to visit a libstdc++ variant: https://godbolt.org/g/kSmBTg While gcc doesn't reject such code, that seems like an access checking bug. This patch makes the offending _M_u member accessible for the rest of the code. 2017-02-07 Ville Voutilainen <ville.voutilainen@gmail.com> Fix an access problem in variant. * include/std/variant (variant): Add a using-declaration for _Base::_M_u.