Support inheriting jobserver when using `cargo run`

[petrochenkov]

Problem

Sometimes commands run through cargo run actually perform build actions for a larger build system.

For example in #10511 (comment) the scenario is running something like cargo run -p binding_generator which generates headers to be used during the build later.

And in rust-lang/rust#113730 (comment) cargo-miri is set as target.runner and runs as a part of cargo run (and calls build tools like cargo and rustc recursively).

Proposed Solution

In all cases like these cargo shouldn't close its jobserver file descriptors (or other handles), but pass them to the tool being run instead.

I think doing this under an options would be fine.
The default for such option can be decided upon later (probably kept being false, which is equivalent to the current behavior).

Notes

No response

[RalfJung]

In all cases like these cargo shouldn't close its jobserver file descriptors (or other handles), but pass them to the tool being run instead.

From what I understood in the PR, this does not seem to be what the PR does. The PR only makes it so that if cargo uses an external jobserver, that one is now propagated to cargo run as well.

So maybe the issue should be reopened?

[weihanglo]

From reading this issue title, and the context of #10511 (comment), I made an assumption that miri (or some other tool alike) would like to inherit existing jobserver from the environment, exactly as how Cargo treats external commands today since #10511. #12776 made it so. It's my fault that didn't request more details from the issue author.

The line between compilation and execution is not always clear in cargo, like --keep-going flag. What is kept going, rustc or the final binary run? 🤯

That said, if this doesn't resolve the miri issue, I am sorry 😞. I would suggest opening another issue to clarify the workflow and expectation, and we could consider a piped-based jobserver by default (see PR description in #12776).