Support exporting informations to execute `cargo test` artifact separately

[foriequal0]

Problem

RustRover and rust-analyzer do a two-step method to launch a debug session for the target binary:

1. cargo test --no-run (for rust-analyzer: https://github.com/rust-lang/rust-analyzer/blob/2cf14f4d34fd96fb763cfd9f909472a61145674a/editors/code/src/toolchain.ts#L54)
2. execute the artifact by themselves.

But they don't set environment variables as cargo test does at the second step.

There are at least two kinds of environment variables that cargo sets:

1. Dynamic library path (https://github.com/rust-lang/cargo/blob/2da24c9172cd638f63713aa191c9aff51c16f476/src/doc/src/reference/environment-variables.md#dynamic-library-paths)
2. Environment variables from Cargo config (https://github.com/rust-lang/cargo/blob/2da24c9172cd638f63713aa191c9aff51c16f476/src/doc/src/reference/config.md#env)
3. Accidential ones? (https://github.com/rust-lang/cargo/blob/2da24c9172cd638f63713aa191c9aff51c16f476/src/doc/src/reference/environment-variables.md#environment-variables-cargo-sets-for-crates)

rust-analyzer doesn't set all of them, while RustRover sets the 2. and (part of)3. (YouTrack issue)

I guess it's time to introduce a standard supporting mechanism for that?

Proposed Solution

some flags to print them (--print-info?)

{
  "executable": ".../target/debug/deps/...",
  "arguments": [ ... ],
  "environment_variables": {
    "FOO": "BAR",
    "LD_LIBRARY_PATH": "...",
    "CARGO_PKG_AUTHORS": "",
    ...
  }
}

generate new message (when --message-format=json is used)

make some

impl<'a> Message for DryRun<'a> {
    fn reason(&self) -> &str {
        "dry-run"
    }
}

and print this when --no-run is given?

{
  "reason": "dry-run",
  "executable": ".../target/debug/deps/...",
  "arguments": [ ... ],
  "environment_variables": {
    "FOO": "BAR",
    "LD_LIBRARY_PATH": "...",
    "CARGO_PKG_AUTHORS": "",
    ...
  }
}

Notes

No response

[epage]

There may also be artifact deps (unstable) and more things in the future.

Personally, I would lean towards the json message. We do want to work towards plumbing commands (https://github.com/crate-ci/cargo-plumbing) and we need to work out the schema for that but I feel like the information mentioned in this is universal enough that we likely don't need to block on plumbing commands because they would likely add context and not change or remove any of that.

With that in mind though, I don't think I would make this exclusive to dry-run.

I'd likely name environment_variables as env.

Or maybe it should be env_set in case we want to add env_remove and env_clear? Maybe env can be implicitly read as env_set and we can keep things simple for now, unsure.

I assume arguments (do we have an existing way we refer to this in our json or docs?) would include the arguments the caller passed in to cargo test that need to be forwarded to the libtest binary.

What about arguments that cargo implicitly sets for harness=false, like --quiet? Or when we switch to specifying --format=json e.g. for #6151?

[foriequal0]

With that in mind though, I don't think I would make this exclusive to dry-run.

I think it should be "execute" or "executable" then.

I'd likely name environment_variables as env.

I agree.

Or maybe it should be env_set in case we want to add env_remove and env_clear? Maybe env can be implicitly read as env_set and we can keep things simple for now, unsure.

How about following how std::sys::process::env::CommandEnv does?

struct ExecuteEnv {
  clear: bool,
  vars: BTreeMap<String, Option<String>>
}

It removes 1 degree of freedom from the applying order.

I assume arguments (do we have an existing way we refer to this in our json or docs?) would include the arguments the caller passed in to cargo test that need to be forwarded to the libtest binary.

Yes, it would.
I couldn't find any appropriate example for this in this project, but I see more usages for args than arguments. Also, Rust uses args consistently within standard libraries.

What about arguments that cargo implicitly sets for harness=false, like --quiet? Or when we switch to specifying --format=json e.g. for #6151?

I'm more inclined to include them for consistency between direct invocation using cargo test and debugging sessions.

Additionally, I realized that we should also include the working directory (current_dir)

[foriequal0]

I'm not sure whether I would open a PR for this, but this is what it looks like if I implement this:
https://github.com/foriequal0/cargo/compare/master..feature/machine-message-executable/

[epage]

What about arguments that cargo implicitly sets for harness=false, like --quiet? Or when we switch to specifying --format=json e.g. for #6151?

I'm more inclined to include them for consistency between direct invocation using cargo test and debugging sessions.

The question is whether people want to reproduce things like cargo or customize the invocation.

I'm not sure whether I would open a PR for this, but this is what it looks like if I implement this:
https://github.com/foriequal0/cargo/compare/master..feature/machine-message-executable/

I've moved this to "needs team input" (not "accepted") but if it is put behind an unstable flag then the bar is lower.

[epage]

I wonder if cargo build --all-targets should also expose this.

[epage]

CC @sunshowers

[sunshowers]

This would be cool! My strategy in nextest has been to look at Cargo's source code and emulate what it does. Providing environment variable info in an structured form would certainly make that more robust.