[DO NOT MERGE] is main broken?

[shwina]

Description

closes

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: ff4584ce-69a5-42d1-9182-7575a8579d99

📥 Commits

Reviewing files that changed from the base of the PR and between dcab690 and 63df4c9.

📒 Files selected for processing (1)

• libcudacxx/include/cuda/std/__tuple_dir/tuple_constraints.h

---

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 investigates potential breakages in the main branch related to zip iterator functionality and single-element tuple construction. It includes a revert of a previous deletion and fixes to tuple constraint logic in libcu++.

Changes

CI Configuration (ci/matrix.yaml)

Added an override workflow entry to run a proof-of-concept build for the thrust project with:

• C++17 standard
• CUDA Toolkit 12.0
• Host compilers: gcc7 and msvc14.39
• Annotated as "PROOF-OF-MAIN-BREAKAGE" to isolate issues with the old toolchain

CUDA libcudacxx Tuple Constraints (libcudacxx/include/cuda/std/__tuple_dir/tuple_constraints.h)

Reverted deletion: Restored tuple_of_iterators_hack that was previously removed.

Refactored tuple-like construction logic:

1. __tuple_select_tuple_like_constructible: Updated to directly gate on per-element is_constructible_v checks, with implicit/explicit selection based on per-element is_convertible_v for variadic paths. Single-element path now uses single-element is_convertible_v checks instead of pack-based expressions.

2. __tuple_nothrow_tuple_like_constructible: Replaced the previous fold-expression approach with an overload set that:

   • Handles non-empty tuples by checking the first element's is_nothrow_constructible_v and recursively evaluating remaining elements
   • Includes explicit base case for empty tuple types

These changes address constructor behavior issues for single-element tuple-like types that may have been causing failures in the main branch.

Walkthrough

CI override matrix added for thrust on CTK 12.0 with older host toolchains. Tuple constraint helpers refined to evaluate constructibility and nothrow properties per-element rather than via pack folds, improving implicit/explicit selection precision.

Changes

CI Matrix Configuration

Layer / File(s)	Summary
Thrust override matrix entry ci/matrix.yaml	New override entry runs build job for thrust with C++17 on CTK 12.0 using gcc7 and msvc14.39 host compilers.

Tuple Constraint Logic

Layer / File(s)	Summary
Tuple-like constructibility selection refinement libcudacxx/include/cuda/std/__tuple_dir/tuple_constraints.h	__tuple_select_tuple_like_constructible variadic path now gates directly on per-element is_constructible_v and determines implicit vs explicit via per-element is_convertible_v; single-element overload reworked for constraints and now uses element-specific convertibility instead of pack folds.
Tuple nothrow constructibility refactor libcudacxx/include/cuda/std/__tuple_dir/tuple_constraints.h	__tuple_nothrow_tuple_like_constructible replaced pack fold with recursive overload set: non-empty tuples check first element's nothrow constructibility and recurse on remainder, with explicit base case for empty tuple packs.

---

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

[miscco]

Those constraints were eagerly evaluated by gcc, which should not have happened

[github-actions]

😬 CI Workflow Results

🟥 Finished in 1h 24m: Pass: 50%/2 | Total: 2h 26m | Max: 1h 24m | Hits: 14%/17838

See results here.