Tracking Issue: Exposing RUSTFLAGS in cargo

[epage]

RUSTFLAGS is a low level mechanism

• Harder for users to discover features
• Harder for cargo to reason about like in #5931

This is meant to track the RUSTFLAGS that should have a cargo-native way of being exposed. This won't always be one-to-one mappings and won't necessarily cover every rustc CLI feature.

• [x] --allow, --deny, --warn
  • Use case: package-level control over warnings

  • 12115

• [ ] --allow, --deny, --warn
  • Interactively denying/allowing warnings

  • 8424

• [ ] --target-cpu=native

  • 2535

• [ ] --cfg
  • https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618
• [ ] -Cinstrument-coverage

  • 13040

• [ ] -C target-feature

  • 14524

Note: Keep in mind the cargo-native solution could live in:

• Cargo.toml: if this is something considered static for the project
• .cargo/config.toml (which includes env, cli): if this is something that changes between environments (including users and platforms) or is transient
• CLI: if this is something that changes from run to run and needs the extra visibility

See also

• https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Reasons.20people.20use.20RUSTFLAGS
• https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Per-user.20build.20caches

[soloturn]

@epage is this the same as people always discuss when finding the config language toml is ok, but not ideal? compared to:

• ron: https://github.com/ron-rs/ron
• cuddle: https://kdl.dev
• dhall: https://dhall-lang.org/

[epage]

This issue is about finding ways to expose environment config as project config and is unrelated to what format is used for either

[kornelski]

Would it make sense to support arbitrary unstable rustc flags, which are project-specific or profile-specific?

For example, there's -Z location-detail=none that I'd like to set in release profile.

Cargo probably won't rush to add first-class options for rustc features that haven't been stabilized yet. OTOH without Cargo's help, they still require RUSTFLAGS.

Maybe something like:

cargo-features = ["unstable"]

[profiles.release]
unstable = {
    location-detail = "none"
}

[epage]

Would profile rustflags be a way of handling this since you are already using unstable features anyways?

This issue is more about how to create abstractions for uses of rustflags. Creating another pass-through mechanism doesn't seem in the spirit of this issue.

[Kixunil]

Some perspective from various production projects:

• having only the [lints] table and no command-line options is not sufficient - there's a use case when one wants to simply check if a crate uses unsafe to decide whether it's worth running miri on the crate or not. This also implies that --forbid is needed. (The check is cargo check with -F unsafe-code and if it fails run miri, skip otherwise.)
• Generally, it's not sufficient to have something configurable via Cargo.toml because CI might need to change things and patching a toml to do that is fragile.
• Limiting --target-cpu to just native sounds strange, but thankfully not my problem (yet)
• When testing code under miri one often wants to enable target-features to make sure unsafe SIMD code gets checked. And because maintaining lists of features to enable is tiresome, the straightforward approach is to enable everything except crt-static. --enable-all-simd-target-features would be nice.
• --cfg, definitely, this is a big one. Not just for mutually exclusive features but also for various debugging purposes. Also it's weird that cargo bench does not set bench cfg already.
• -C link-arg selecting a linker script is needed for embedded (but maybe there are better ways?)
• Sanitizers, obviously, often used with force-frame-pointer=yes
• Linker selection

[epage]

Please keep in mind that this is a tracking issue. If you have specific requests, feel free to open an issue and we can add it to this. Trying to have too much design discussion for these individual items here will likely get them lost in the noise as this tracking issue covers a wide breadth of features.

having only the [lints] table and no command-line options is not sufficient - there's a use case when one wants to simply check if a crate uses unsafe to decide whether it's worth running miri on the crate or not. This also implies that --forbid is needed. (The check is cargo check with -F unsafe-code and if it fails run miri, skip otherwise.)

Do we need to provide an abstraction over this or continue to leave it to RUSTFLAGS?

Generally, it's not sufficient to have something configurable via Cargo.toml because CI might need to change things and patching a toml to do that is fragile.

This issue is not prescriptive about where they may live and where they will live depends on circumstances.

They could live

• In Cargo.toml: if this is something considered static for the project
• In .cargo/config.toml (which includes env, cli): if this is something that changes between environments (including users and platforms) or is transient
• In CLI, if this is something that changes from run to run

12738 is our issue for identifying environment config (.cargo/config.toml) that should live in project config (Cargo.toml) and find a way to migrate it.