concept error: satisfaction of atomic constraint '....' depends on itself

Question

I am using the following concepts to identify a map-like type, but it causes a cryptic error within the range-v3 v.0.12 library when used with GCC-11 or GCC-12 on linux:

template < typename MapLike >
concept mapping = requires(MapLike m) {
                     // has to be key-value-like to iterate over values and keys only repsectively
                     ranges::views::keys(m);
                     ranges::views::values(m);
                  };

template < typename MapLike, typename KeyType >
concept maps = mapping< MapLike >
               and std::is_convertible_v<    // map's key type has to be convertible to the given key type
                  decltype(*(ranges::views::keys(std::declval< MapLike >()).begin())),
                  KeyType >;

and I am using it in combination with this example class that was supposed to be constructible from any map-like type

template < typename T >
class Hashmap {
  public:
   using map_type = std::unordered_map< T, double >;

   template < maps< T > U >
   Hashmap(U&& action_value_pairs)
       : m_map()
   {
      for(const auto& [key, value] : action_value_pairs) {
         m_map.emplace(key, value);
      }
   }

   Hashmap(std::initializer_list< std::tuple< T, double > > init_list)
       : m_map()
   {
      for(const auto& [key, value] : init_list) {
         m_map.emplace(key, value);
      }
   }


   inline auto begin() { return m_map.begin(); }
   [[nodiscard]] inline auto begin() const { return m_map.begin(); }
   inline auto end() { return m_map.end(); }
   [[nodiscard]] inline auto end() const { return m_map.end(); }

  private:
   map_type m_map;
};


int main(){

    Hashmap< int > m{std::pair{0, 5.}, std::pair{1, 2.}, std::pair{2, 3.}};
    for(auto v : m | ranges::views::values) {
        std::cout << v << "\n";
    }
    
}

the error message goes deep within the range-v3 concepts:

/opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp: In instantiation of 'constexpr auto ranges::views::all_fn::operator()(T&&) const [with T = const Hashmap&]': /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp:91:35: required by substitution of 'template requires (viewable_range) && (input_range) && (kv_pair_like_<decltype( (declval<decltype(ranges::_::begin(static_cast<Rng& ( )()noexcept (true)>(nullptr)()))&>)())>) ranges::keys_range_view<decltype (ranges::views::all(declval()))> ranges::views::keys_fn::operator()(Rng&&) const [with Rng = const Hashmap&]'

:15:41: required by substitution of 'template requires maps Hashmap::Hashmap(U&&) [with U = int]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1153:13: required from 'constexpr auto ranges::views::all_fn::operator()(T&&) const [with T = Hashmap&]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/view/all.hpp:91:35: required by substitution of 'template requires (viewable_range) && (input_range) && (kv_pair_like_(nullptr)()))&>)())>) ranges::values_view()))> ranges::views::values_fn::operator()(Rng&&) const [with Rng = Hashmap&]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/functional/invoke.hpp:140:34: required by substitution of 'template constexpr decltype ((F&&)(f)((Args&&(ranges::invoke_fn::operator()::args))...)) ranges::invoke_fn::operator()(F&&, Args&&...) const [with F = ranges::views::values_fn; Args = {Hashmap&}]' /opt/compiler-explorer/libs/rangesv3/0.12.0/include/range/v3/functional/concepts.hpp:40:5: required by substitution of 'template requires (viewable_range) && (invocable_view_closure) constexpr auto ranges::views::view_closure_base_ns::operator|(Rng&&, ranges::views::view_closure) [with Rng = Hashmap&; ViewFn = ranges::views::values_fn]':60:36: required from here /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1151:21: required for the satisfaction of 'constructible_from' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1170:9: required for the satisfaction of 'copy_constructible_concept_' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1181:21: required for the satisfaction of 'copy_constructible' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1209:21: required for the satisfaction of 'copyable' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1217:21: required for the satisfaction of 'semiregular' [with T = Hashmap] cc1plus: error: satisfaction of atomic constraint '__is_constructible(T) [with Args = {const I}; T = I]' depends on itself /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1151:21: required for the satisfaction of 'constructible_from' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1170:9: required for the satisfaction of 'copy_constructible_concept_' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1181:21: required for the satisfaction of 'copy_constructible' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1209:21: required for the satisfaction of 'copyable' [with T = Hashmap] /opt/compiler-explorer/libs/rangesv3/0.12.0/include/concepts/concepts.hpp:1217:21: required for the satisfaction of 'semiregular' [with T = Hashmap] cc1plus: error: satisfaction of atomic constraint '__is_constructible(T) [with Args = {const I}; T = I]' depends on itself

I am using this concept in my code to filter out maps over certain key types (maybe this isn't the best way) and this error has been bugging me for a while now.

The problem exists with the range-v3 library for GCC 11/12, but it does work under clang 14+: https://godbolt.org/z/dqj1YY9e4

The problem does not exist with std::ranges for GCC, but it does for clang now: https://godbolt.org/z/a88WMe66b

Is this a bug in GCC, clang, or range-v3?

I generally code my project for GCC and c++20 (hence the range-v3 library due to the greater feature count). Is there a way to get the idea of my concept to work with GCC and range-v3?

Answer 1

If you use non qualified calls in your concepts, it works:

https://godbolt.org/z/TWr39eaGr