Ensure Send/Sync impl for std::process::CommandArgs

[Mark-Simulacrum]

This also adds static assertions to ensure this continues to hold across all targets. I think today this was just missing on cfg(unix) targets, but haven't checked too thoroughly. I think all tier 2+ targets continue to compile with the assertions (but we'll see what CI says).

cc #154517

[rustbot]

@Mark-Simulacrum: no appropriate reviewer found, use r? to override

[Amanieu]

@rfcbot merge libs-api

[rust-rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[Mark-Simulacrum]

r? libs

[clarfonthey]

Main apprehension right now is that the test is lifetime-based, which technically could fail for bad reasons if we only implemented the markers for static lifetimes, but I don't quite have in my head what the suitable alternative would be.

[Mark-Simulacrum]

Maybe it works to put for<'a> Ty<'a> there?

My feeling is that the assertions are more defense in depth than anything else though, and I think it's very unlikely we'd have a lifetime-dependent Send or Sync (or any other auto trait) implementation.

[clarfonthey]

Oh, I agree with you there, I just think there may be a way to make it work in all cases anyway and want to try that out if we can.

Might be as simple as adding a second function intermediary which has a lifetime parameter.

[Mark-Simulacrum]

Ah, right, for<'a> Ty<'a> won't work, that syntax only works in trait bounds today. I think maybe there's some way to express the condition we want (indirecting via a trait impl, perhaps?) but I'm not personally feeling that any additional complexity is warranted here. If you can come up with a simple way to express the more general condition happy to apply it, otherwise I'm inclined to move forward as-is if you don't object.

[clarfonthey]

To be clear, my plan was to actually do that, I just hadn't gotten around to it yet: basically, I'd like to try my hand at making a version that works so it can be useful as a template, but if I can't figure it out, I'll just merge as-is.

[clarfonthey]

After experimenting a bit, I guess that we have explicitly ensured this can't happen:

error[E0366]: `!Send` impls cannot be specialized
--> library/std/src/process.rs:1314:1
|
1314 | impl !Send for CommandArgs<'static> {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and so:

@bors r+ rollup

[rust-bors]

📌 Commit c08e6e4 has been approved by clarfonthey

It is now in the queue for this repository.