Introduce `core::marker::Tuple` to properly type-check `extern "rust-call"` calls

[compiler-errors]

Proposal

Introduce core::marker::Tuple as a (for now, perma-unstable) builtin marker trait that is auto-implemented for all tuples, and require that calls to (and probably other related operations, like ptr coercion to) the extern "rust-call" ABI enforces that the tupled argument type implements core::marker::Tuple. Generic "rust-call" APIs will need to constrain their arguments, such as:

-impl<Args, F: FnOnce<Args> + ?Sized, A: Allocator> FnOnce<Args> for Box<F, A> {
+impl<Args: Tuple, F: FnOnce<Args> + ?Sized, A: Allocator> FnOnce<Args> for Box<F, A> {
     type Output = <F as FnOnce<Args>>::Output;

     extern "rust-call" fn call_once(self, args: Args) -> Self::Output {
         <F as FnOnce<Args>>::call_once(*self, args)
     }
 }

This really should be reflected in the type system, since we can't fully enforce that nested calls involving type parameters are actually tuples until monomorphization, but span information is lacking during monomorphization (and so is bubbling up errors at that point) and properly denying bad "rust-call" usages has to be threaded through each codegen crate.

For now, the scope of this marker trait is limited just to properly type check this quirk of the "rust-call" ABI. Further proposals will be needed if interest exists to flesh out this marker trait into something that can be used to introspect more tuple info (e.g. arity).

See: rust-lang/rust#99820, bjorn3/rustc_codegen_cranelift#1236, rust-lang/rust#66696. More probably exist.

Mentors or Reviewers

Anyone on t-compiler{,-contributors} who's familiar with rustc_typeck and rustc_trait_selection should be able to review. Changes should be pretty trivial, and I've got a working branch already in compiler-errors/rust@tuple-marker. _{it needs some diagnostic cleanup, but that's basically it...}

Process

• [x] File an issue describing the proposal.
• [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[compiler-errors]

Also not sure if this is better as a t-lang proposal. On one hand, the Fn* traits are pretty well known, on the other, there are not one but two unstable features you need to enable to use Fn* traits in your own (nightly) code.

[eddyb]

@rustbot second ^{_{(I've been wanting to do some things in this area, and was expecting to remain WF-unsound for a while w/o a Tuple trait)}}

[crlf0710]

cc @rust-lang/types

[apiraino]

@rustbot label -final-comment-period +major-change-accepted