Fix recursive constraint satisfaction in resource_ref construction fr…

[Adityakk9031]

closes #8037

Fix a recursive constraint-satisfaction error that occurs in GCC 14+ (C++20) when constructing cuda::mr::resource_ref from a type that:

Publicly inherits from cuda::mr::shared_resource, and
Has a constructor accepting

resource_ref
Root Cause

resource_ref
was backed by __basic_any<__iasync_resource<Ps...>&>. The __iasync_resource interface includes __icopyable<>, which causes the compiler to evaluate copyable → is_constructible<T, T&> → overload resolution discovers

T(resource_ref)
→ checks if T& converts to

resource_ref
→ re-enters the original __satisfies<T, __iasync_resource<...>> check → cycle.

Fix

Introduced two new interface aliases that omit

__icopyable
:

cpp
template <class... _Properties>
using __iresource_ref = ::cuda::
__iset<__ibasic_resource<>, __iproperty_set<_Properties...>, ::cuda::__iequality_comparable<>>;
template <class... _Properties>
using __iasync_resource_ref = __iset<__iresource_ref<_Properties...>, __ibasic_async_resource<>>;

resource_ref
and synchronous_resource_ref now use these. The owning types (

any_resource
,

any_synchronous_resource
) are unchanged — they still include

__icopyable
because they own the resource by value.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ericniebler]

this is the wrong fix. it doesn't address the root of the issue, which i describe (and fix) in #8121.