[Bug c++/92894] "declared using local type 'test01()::X', is used but never defined" during concept satisfaction

["ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> The following should compile, because the undefined member function is never
> odr-used, only its return type is needed.

Hmm.. don't we end up odr-using the undefined member function when checking the 

   { ranges::iter_move(__in) } -> same_as<iter_rvalue_reference_t<_In>>;

requirement of the concept __indirectly_readable_impl (as part of the concept
indirect_unary_predicate)?

In order to verify this requirement we need to determine the return type of
ranges::iter_move(__in).  But the operator() of this CPO has a decltype(auto)
return type, so determining its return type requires instantiating its body:

      struct _IMove
      {
        template<typename _Tp>
          requires __adl_imove<_Tp> || requires(_Tp& __e) { *__e; }
          constexpr _Blah<_Tp>::type
          operator()(_Tp&& __e) const
          noexcept(_S_noexcept<_Tp>())
          {
            if constexpr (__adl_imove<_Tp>)
              return iter_move(static_cast<_Tp&&>(__e));
            else if constexpr (is_reference_v<iter_reference_t<_Tp>>)
              return std::move(*__e);
            else
              return *__e;
          }
      };

And this instantiated function body (the second branch of the constexpr if)
would then odr-use this undefined member function, IIUC.

So could this be another example where defining the operator() of a CPO with a
deduced return type leads to excessive instantiation?