Skip to content

Conversation

@legrosbuffle
Copy link
Contributor

The extents type of the left hand side of those assignment are extents<i_t, FJ_MOVE_SIZE, raft::dynamic_extent>. But the extents type created on the right hand side by raft::make_extents<i_t>((i_t)FJ_MOVE_SIZE, (i_t)fj.pb_ptr->n_variables)) are extents<int, dynamic_extents, dynamic_extents>.

The former is constructible from the latter, but the documentation specific that this conversion is explicit:

"This constructor is explicit if ((Extents != std::dynamic_extent && OtherExtents == std::dynamic_extent) || ...) is true"

The above condition holds in our case: (FJ_MOVE_SIZE != dynamic_extent && dynamic_extents == dynamic_extent) for the first extent.

This ctor being explicit translates to the ctor of the mdspan being explicit, so in C++20, when the compiler enforces explicitness, we need to give it the exact extents type.

The extents type of the left hand side of those assignment are `extents<i_t, FJ_MOVE_SIZE, raft::dynamic_extent>`.
But the extents type created on the right hand side by `raft::make_extents<i_t>((i_t)FJ_MOVE_SIZE, (i_t)fj.pb_ptr->n_variables))`
are `extents<int, dynamic_extents, dynamic_extents>`.

The former is constructible from the latter, but the documentation specific
that this conversion is *explicit*:

"This constructor is explicit if `((Extents != std::dynamic_extent && OtherExtents == std::dynamic_extent) || ...)` is true"

The above condition holds in our case: (`FJ_MOVE_SIZE != dynamic_extent && dynamic_extents == dynamic_extent)` for the first extent.

This ctor being explicit translates to the ctor of the mdspan being explicit, so in C++20, when
the compiler enforces explicitness, we need to give it the exact extents type.
@legrosbuffle legrosbuffle requested a review from a team as a code owner June 26, 2025 07:24
@copy-pr-bot
Copy link

copy-pr-bot bot commented Jun 26, 2025

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.

@aliceb-nv aliceb-nv added non-breaking Introduces a non-breaking change improvement Improves an existing functionality labels Jun 26, 2025
@aliceb-nv
Copy link
Contributor

/ok to test 810cb78

Copy link
Contributor

@hlinsen hlinsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! lgtm

@rgsl888prabhu
Copy link
Collaborator

/merge

@rapids-bot rapids-bot bot merged commit 2deedf2 into NVIDIA:branch-25.08 Jun 26, 2025
72 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants