Note: CodeRabbit is enabled on this repository as a convenience for maintainers
and contributors. Use your best judgment when considering its review comments and
suggestions — a suggested change may be inadequate, unnecessary, or safe to ignore.
Contributors are not expected to address every comment. Human reviews are what
ultimately matter for merging.

Overview

This PR fixes a broken sequence-detection trait used by the arguments framework. The previous element-type-based logic misclassified many types (e.g., treating tuple/complex-like types and certain wrapper-like types as sequences and preventing iterators/pointers from being passed as single values). The new definition narrows what is considered a sequence to arrays, types satisfying ranges::range, or types that provide random-access traversal. Tests were added/updated to lock in this behavior and avoid regressions.

Changes

Implementation (libcudacxx/include/cuda/__argument/argument.h)

• Rewrote __is_sequence_v:
  • New definition: is_array_v<remove_cvref_t<_Tp>> || ranges::range<_Tp> || __has_random_access_traversal<_Tp>.
• Removed the old element-type-based helpers (previous __is_single_value_v / __is_iterable_v logic is gone).
• Adjusted trait defaults:
  • Primary __traits_impl<_Tp>::is_single_value behavior no longer depends on the removed helper; trait queries now reflect the new classification (pointers/iterators are treated differently by the trait).
• Runtime validation updates:
  • __immediate::__validate_value continues to validate single-value arithmetic cases.
  • __immediate_sequence::__validate_value:
    • If __has_random_access_traversal<_Arg> is true, the random-access branch is taken (the body contains a FIXME noting that sequence size may be unknown).
    • Otherwise, if __is_sequence_v<_Arg> and the deduced element type is arithmetic, the code iterates the range and validates each element.
• Updated static_assert text for __constant_sequence to require a “sequence” (range or array).

Tests

• libcudacxx/test/libcudacxx/cuda/argument/argument_traits.pass.cpp
  • Added negative assertions that cuda::std::complex, pair, tuple, optional, expected are not sequences.
  • Confirmed wrapper-like types (range_like, element_type_like, value_type_like) are not sequences.
  • Confirmed pointers and counting_iterator are sequences when they provide random-access traversal; bidirectional iterators are not.
  • Kept C arrays, std::span, and std::array classified as sequences.
  • Updated trait expectations: e.g., __traits<int*>::is_single_value is now asserted true (reflecting the trait primary-template change).
• libcudacxx/test/libcudacxx/cuda/argument/dynamic_argument.pass.cpp and static_argument.pass.cpp
  • Swapped prior __is_single_value_v assertions to use !__is_sequence_v where appropriate for unwrapped/value_type checks.
• libcudacxx/test/libcudacxx/cuda/argument/usage_example.pass.cpp
  • Disabled one plain-span integration test block with #if 0 and a FIXME comment (tagged FIXME(miscco)).

Rationale & Impact

• Aligns sequence detection with standard range terminology while preserving practical handling for random-access iterators/pointers where historically accepted.
• Prevents misclassification of tuple-like or scalar-like types (e.g., std::complex) as sequences.
• Tests broaden negative coverage to prevent regressions.
• Remaining concern: runtime validation for random-access iterator/pointer sequences uses a random-access path with a FIXME (size unknown). Reviewers may consider whether additional iterator-size/validation strategies, clearer documentation, or different trade-offs for treating iterators/pointers as sequences are needed.

Notes for reviewers

• Verify the trade-off where __is_sequence_v is narrowed to ranges/arrays/random-access traversal but trait defaults were adjusted so pointer/iterator cases can still appear as single values in trait queries — ensure that matches CUB compatibility goals.
• Consider whether the FIXME in the random-access validation path requires concrete follow-up (e.g., explicit size handling or requiring spans/views when bounds are needed).

suggestion:

Walkthrough

Reclassifies sequence detection: a sequence is now an array (after cv/ref removal), a ranges::range, or has random-access traversal; removes __is_single_value_v/__is_iterable_v; updates immediate-sequence validation, trait primary template, and tests to use __is_sequence_v (negated for single-value).

Changes

Argument type classification by ranges::range

• Possibly related PRs:

  • NVIDIA/cccl#8875: Related changes to argument.h sequence/single-value trait logic.

• Suggested reviewers:

  • ericniebler
  • gevtushenko
  • davebayer

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

I have added some more tests to make sure this does not regresses again. I believe we can agree that complex<float> is not a range

I am not tied to the name of this trait, but at the end of the day when user passes something that has bounds we need to understand if its one value or multiple values. We have the _sequence wrappers for that, but I wanted to provide some validation in it, this trait was supposed to answer if the thing in the wrapper looks like multiple values and what is the element type, so we can assert the values are within bounds.

I highly doubt we can convince others CUB should stop accepting iterators and pointers, so I believe we need a broader definition than just range, but maybe we can also remove the extra validation, which would remove the need for this trait. But it is likely in that case a similar trait would need to live in CUB anyway, so I am not sure if it isn't just pushing the problem to a different place

I highly doubt we can convince others CUB should stop accepting iterators and pointers

We should be able to still allow pointers and iterators if that is intended, but then the check should probably be __has_random_access_traversal or similar

Also we need to then differentiate iteration over a range and iteration over an iterator. Currently the check in __validate_value only considered ranges and not iterators

The issue I have here is that a pointer / iterator does not communicate the size of the range. In a perfect world we would just pass transform_view rather than transform_iterator

Not a hill to die on definitely but I at least want to make sure that we do not consider tuple or complex as sequences

🥳 CI Workflow Results

🟩 Finished in 1h 38m: Pass: 100%/118 | Total: 23h 21m | Max: 55m 15s | Hits: 98%/342444

See results here.