Target runner support

[roblabla]

Cargo has a cute little-known feature that allows running binaries for other targets directly from the cargo commands. This works by having a runner configured for a given target triplet in the cargo configuration. From the cargo reference:

If a runner is provided, compiled targets for the $triple will be executed by invoking the specified runner executable with actual target as first argument. This applies to cargo run, cargo test and cargo bench commands. By default compiled targets are executed directly.

The usual use-case would be running the tests through qemu to make sure it works on different architecture (Running it under qemu-aarch64 to make sure it works on aarch64, etc...).

When escargot spawns a process as part of a CargoTest, it should ideally recover the runner and use it to run the test. This would require reading the .cargo/configs to get the appropriate runner, and running the test as ./runner ./test --testargs (instead of ./test --testargs)

[epage]

I'm assuming this applies to both CargoTest and CargoRun.

Reading [target.$triple] on our own shouldn't be too bad. I'd b concerned about having to re-implement support for [target.'cfg(...)'] and we might need to look into another way of handling that part.

[epage]

parse_cfg could help though it doesn't offer the actual matching logic.

Could probably steal the matching logic from runtime_cfg. I'm thinking we shouldn't use the crate directly because it is focused on handling ASTs for macros.

[roblabla]

In cargo:

The logic to get the runner can be found here. As we can see, the logic is to figure out if two cfgs "match" through the matches_key function.

The cfg we are interested in is bcx.target_info.cfg(). target_info is a member of BuildContext. target_info itself is created based on the target, and basically calls rustc to figure out all its members.

So I straced rustc to figure out how it happens behind the scenes and here is how it's called:

rustc - --crate-name ___ --print=file-names $RUSTFLAGS --target $TARGET --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg < /dev/null

(The --target is optional.)

This outputs something of the form:

___
lib___.rlib
lib___.so
lib___.so
lib___.a
lib___.so
/home/roblabla/.rustup/toolchains/stable-x86_64-unknown-linux-gnu
debug_assertions
proc_macro
target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_os="linux"
target_pointer_width="64"
target_vendor="unknown"
unix

First line is crate name, 5 lines below are the names of the various crate types, the line below is the sysroot, and everything afterwards is a cfg. Every such cfg line is parsed with Cfg::from_str, and assembled into our final Vec that we'll use for our final comparison.

So I think this behavior should be fairly easy to replicate without too much trouble. None of this seems to use unstable flags, so it should all be stable to use? Might be a good idea to ask the cargo/rustc maintainers first though.

EDIT: 🤔 something interesting: cfg(feature = "") don't seem to be usable there. Cargo doesn't pass the --cfg features to rustc when asking it for the supported cfgs.