26

The following code:

variant<string> x = "abc";
cout << get<string>(x) << "\n";

works fine under g++ (version 7.2). However, when compiled under clang++ (version 5.0) using libstdc++, I get the following error in the get method:

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/variant:238:46: fatal error: cannot cast 'std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >' to its private base class 'std::__detail::__variant::_Variant_storage<false, std::
__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >'
      return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);

Is this a compiler bug, or is my code illegal in any way?

Barry
  • 286,269
  • 29
  • 621
  • 977
André Wagner
  • 1,330
  • 15
  • 26
  • Did you specify that `libc++` should be used as standard library implementation? IIRC, clang uses libstdc++ by default. – StoryTeller - Unslander Monica Sep 30 '17 at 19:39
  • I can't see what is illegal here, but, if so, this would be a pretty basic thing to mess up... – Sam Varshavchik Sep 30 '17 at 19:40
  • 2
    Given that it works in gcc+libstdc++, works in clang+libc++, but fails in clang+libstdc++, the most likely case is that it's a subtle incompatibility between clang and libstdc++. An answer should point out exactly what the incompatibility is though. –  Sep 30 '17 at 19:41
  • heh. hit this same issue today. – Jagoly Oct 01 '17 at 07:43

1 Answers1

24

This is caused by clang bug 31852 (and also 33222), whose reproduction courtesy of Jonathan Wakely should look very relevant:

template<typename V> auto get(V&) { }

template<typename>
class variant
{
    template<typename V> friend auto get(V&);
};

int main()
{
  variant<int> v{};
  get(v); // error: ambiguous 
}

clang doesn't properly recognize friend declarations that have placeholder types. Which is exactly how libstdc++ implements std::get:

// Returns the typed storage for __v.
template<size_t _Np, typename _Variant>
constexpr decltype(auto) __get(_Variant&& __v)
{
    return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);
}

this accesses a private member of variant, but this function is properly declared a friend:

template<size_t _Np, typename _Vp>
friend constexpr decltype(auto) __detail::__variant::__get(_Vp&& __v);

libstdc++'s implementation is valid, clang just doesn't think __get is a friend.

Barry
  • 286,269
  • 29
  • 621
  • 977
  • 3
    I think the best and reasonably safe workaround is to use a modified version of libstdc++'s variant header file during development. All you need to change is commenting out the friend declaration and publicly deriving from __detail::_variant::_Variant_base (which gives __get access to the underlying variant storage). I use this to silence tons of errors from clang-tidy while using GCC as the primary compiler and haven't noticed any bad side effects. – Stacker Jan 18 '18 at 14:44
  • 7
    Changing the access of the base class is overkill, just add `public: using _Base::_M_u;` to the end of the `variant` class definition. I've done that in https://gcc.gnu.org/r258854 – Jonathan Wakely Mar 26 '18 at 13:11
  • 1
    This bug has now been fixed! :) – Rakete1111 Sep 12 '18 at 13:25
  • A possible workaround is also to fallback to `boost::variant` when building on pre C++17 and on pre Clang 7. It is header only, and differences are minimal. – Giovanni Cerretani Nov 02 '21 at 09:21