Make ``--target`` not order-sensitive in ``./miri run``

[tiif]

When running ./miri run --dep ./tests/pass-dep/libc/libc-socketpair.rs --target i686-unknown-linux-gnu, it crashes.

The application panicked (crashed).
Message:  called `Result::unwrap()` on an `Err` value: Errored { command: "\"/home/tiif/Documents/miri/target/debug/miri\" \"--edition\" \"2021\" \"--sysroot\" \"/home/tiif/.cache/miri\" \"./tests/pass-dep/libc/libc-socketpair.rs\" \"--target\" \"i686-unknown-linux-gnu\" \"--out-dir\" \"/home/tiif/Documents/miri/target/miri_ui\" \"--print=cfg\" \"--target\" \"x86_64-unknown-linux-gnu\"", errors: [], stderr: [101, 114, 114, 111, 114, 58, 32, 79, 112, 116, 105, 111, 110, 32, 39, 116, 97, 114, 103, 101, 116, 39, 32, 103, 105, 118, 101, 110, 32, 109, 111, 114, 101, 32, 116, 104, 97, 110, 32, 111, 110, 99, 101, 10, 10], stdout: [] }
Location: tests/ui.rs:341

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
error: test failed, to rerun pass `--test ui`
Error: command exited with non-zero code `cargo +miri test -Zroot-dir=/home/tiif/Documents/miri --manifest-path /home/tiif/Documents/miri/./Cargo.toml --test ui --quiet -- --miri-run-dep-mode --edition 2021 --sysroot /home/tiif/.cache/miri ./tests/pass-dep/libc/libc-socketpair.rs --target i686-unknown-linux-gnu`: 101

When running ./miri run --dep ./tests/pass-dep/libc/libc-socketpair.rs (without --target i686-unknown-linux-gnu) it passes.

Is --dep expected to be not compatible with --target?

[RalfJung]

With the recent rework of ./miri I think flags are more order-sensitive now so you may have to pass --target before the filename.

Cc @Mandragorian

[tiif]

Oh yea, when I passed it before the filename, it works.

It seems to happen without --dep too, and the error is also quite confusing.

Error for ./miri run ./tests/pass/shims/io.rs --target aarch64-apple-darwin

error[E0463]: can't find crate for `std`
  |
  = note: the `aarch64-apple-darwin` target may not be installed
  = help: consider downloading the target with `rustup target add aarch64-apple-darwin`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

Passing --target aarch64-apple-darwin in front of the filename also fix this

@rustbot label +A-dev +C-enhancement

[Mandragorian]

tl;dr: By passing the --target after the filename, the target field in the Command:Run variant is left empty, and --target i686-unknown-linux-gnu is included in the field flags of the same variant. This happens because the filename marks the start of the trailing arguments.

Decoding the ascii-encoded text, I saw the actual error as "--target passed more than once".

What I think happened in your original command ./miri run --dep ./tests/pass-dep/libc/libc-socketpair.rs --target i686-unknown-linux-gnu is that clap tried to parse ./tests/pass-dep/libc/libc-socketpair.rs, and didn't recognize it. So it assumed that the trailing var args have begun. so it treated ./tests/pass-dep/libc/libc-socketpair.rs --target i686-unknown-linux-gnu as a vector of strings, which we pass as-is to miri.

However, this left --target unset. And I see in a comment in command.rs, line 604 that when --dep is passed, the target is already passed via an env var. So I am guessing that is why it produced that error.

The --target flag is not exactly order sensitive. It failed because it was after the test's filename, which marks the start of the trailing arguments.

As I was writting this I saw that it also fails when --dep is missing, but maybe this is a different error now, as it is building a sysroot for the system's target (by default), and then it can't find a sysroot for the --target (which is again passed as-is).

[RalfJung]

This is the same problem as what I mentioned recently where ./miri test filter --bless no longer works. So in that sense it is an order-sensitivity issue: all flags that are understood by ./miri must now come before the first non-flag argument.

[Mandragorian]

Yes I agree. I wanted to point out that as long as --target is passed before the non-flag arguments, it can appear in any order.

[tiif]

As I was writting this I saw that it also fails when --dep is missing, but maybe this is a different error now, as it is building a sysroot for the system's target (by default), and then it can't find a sysroot for the --target (which is again passed as-is).

I am not sure what is the issue, but I observed that when I first run ./miri run ./tests/pass/shims/io.rs --target aarch64-apple-darwin, it failed. After that, when I run ./miri run --target aarch64-apple-darwin ./tests/pass/shims/io.rs it passed as expected. But after it passed, subsequent run of ./miri run ./tests/pass/shims/io.rs --target aarch64-apple-darwin started to pass.

[RalfJung]

I am not sure what is the issue, but I observed that when I first run ./miri run ./tests/pass/shims/io.rs --target aarch64-apple-darwin, it failed. After that, when I run ./miri run --target aarch64-apple-darwin ./tests/pass/shims/io.rs it passed as expected. But after it passed, subsequent run of ./miri run ./tests/pass/shims/io.rs --target aarch64-apple-darwin started to pass.

Yeah that makes sense. When ./miri sees the --target flag, it knows that it has to build a sysroot for this target, but once the sysroot is built, the invoked Miri can pick up the sysroot even if ./miri doesn't realize what target is being used.