Consider exposing `target_feature` option in cargo CLI

[Kixunil]

Problem

When testing with miri one often has to enable target features (all SIMD features) to be sure to test SIMD instructions which tend to contain unsafe code. This requires target_feature to be set in both RUSTFLAGS and RUSTDOCFLAGS. Not only is this annoying but also a footgun. From my understanding miri just passes the arguments along so it's a cargo issue.

Proposed Solution

Consider adding an argument that can set the target features as needed. Even better, also have an argument that enables all SIMD features.

Alternatively it could be decided that this is too niche and should be handled by miri and that may be the only tool that currently needs it, in which case I'll be happy to open an issue there.

Notes

I've opened this as requested in https://github.com/rust-lang/cargo/issues/12739#issuecomment-2338147752

[epage]

Is this request specifically for cargo miri? If so, thats actually an external plugin and we'll want to move this issue to the appropriate repo.

[Kixunil]

Hard to say, miri just passes the arguments and maybe this is useful for someone else (compiling to a different CPU?) but I specifically need it for miri only.

[epage]

Keeping it here for now in case we want this on other commands and so we'd want consistency.

You mention CLI. For myself, I'm trying to be particular about what we add to the CLI. The CLI is front and center. As we add new flags, we make it harder to discover the flags that are already there. This means that adding a new flag, while having value for someone, can reduce the value gained by every other CLI flag for everyone. This is a phenomenon I've seen in clap where people ask for "new" features that exist or talk about things being impossible that are built-in. The cost of adding to the CLI is also discussed in https://github.com/rust-lang/cargo/issues/6100#issuecomment-424830873

For the use case given, I wonder if this is justified.

This seems context dependent, like a profile, but machine specific, like the target table. We don't currently have config that encompasses both.

Another approach is we do put this in the CLI but in a generic flag, like rustc -C target-feature=val.

[Kixunil]

Interesting, I can understand that at minimum the --help table gets noisy. I guess the main problems for me are:

• Consistency between RUSTFLAGS and RUSTDOCFLAGS
• Being able to set commonly-used flags in automated way (though I guess this is really miri-specific)

If the generic flag resolves the first problem, then it's already a win.