# Global, simple, universal RUSTFLAGS **URL:** \ **Category:** cargo\ **Created:** [July 8, 2026, 10:33pm UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454 "2026-07-08T22:33:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![nazar-pc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nazar-pc/32/11386_2.png) [@nazar-pc](https://internals.rust-lang.org/u/nazar-pc)\ **Post date:** [July 8, 2026, 10:33pm UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/1 "2026-07-08T22:33:18Z")
I have struggled with RUSTFLAGS more than necessary recently and would like to argue that the defaults as very suboptimal. They make simple things unnecessarily hard for something that I don't think is inherently complex. To be clear, there is a lot of inherent complexity with RUSTFLAGS, but most common cases should not have to touch it and should be much simpler. > **Motivating example 1** > > I was recently helping to enable AVX512 support on Rust stable in `curve25519-dalek`. Unfortunately, this caused [an issue](https://github.com/dalek-cryptography/curve25519-dalek/pull/914) with intermittently available AVX512-capable GitHub Actions runners. > > The gist of it is that CI looked like this: > > ```yaml > test-simd-nightly: > name: Test simd backend (nightly) > runs-on: ubuntu-latest > steps: > - uses: actions/checkout@v3 > - uses: dtolnay/rust-toolchain@nightly > - env: > # This will: > # 1) build all of the x86_64 SIMD code, > # 2) run all of the SIMD-specific tests that the test runner supports, > # 3) run all of the normal tests using the best available SIMD backend. > # This should automatically pick up the simd backend in a x84_64 runner > RUSTFLAGS: '-C target_cpu=native' > run: cargo test --target x86_64-unknown-linux-gnu > > ``` > > And failed like this: > > ```rust > error[E0433]: cannot find `spec_avx512ifma_avx512vl` in `precomputed_straus` > --> curve25519-dalek/src/backend.rs:105:49 > | > 105 | vector::scalar_mul::precomputed_straus::spec_avx512ifma_avx512vl::VartimePrecomputedStraus, > | ^^^^^^^^^^^^^^^^^^^^^^^^ could not find `spec_avx512ifma_avx512vl` in `precomputed_straus` > | > note: found an item that was configured out > --> curve25519-dalek/src/backend/vector/scalar_mul/precomputed_straus.rs:18:9 > | > 14 | / #[curve25519_dalek_derive::unsafe_target_feature_specialize( > 15 | | "avx2", > 16 | | conditional("avx512ifma,avx512vl", curve25519_dalek_backend = "avx512") > | | _____________________________________ - the item is gated behind the `avx512ifma` feature > 17 | )] > 18 | pub mod spec { > | ^^^^ > > ``` > > The reason for this is that while the library was compiled with `RUSTFLAGS`, doc tests were not. So documentation tests were compiled against non-existent API. The solution today is to set `RUSTDOCFLAGS` to the same value. > > I'd argue this behavior makes no sense and is very confusing to someone who have not seen this before. Tests should always run against the same API the crate was compiled with, and `RUSTDOCFLAGS` should be a strict super-set of `RUSTFLAGS` as the result. > **Motivating example 2** > > I've been struggling with enabling of `-Znext-solver=globally` and as of today (`nightly-2026-07-08`) it is still impossible to actually do fully: > > - [Can't specify `-Znext-solver=globally` for proc macros under Miri - The Rust Programming Language Forum](https://users.rust-lang.org/t/cant-specify-znext-solver-globally-for-proc-macros-under-miri/140488?u=nazar-pc) > - [`-Zhost-config` breaks `cargo miri test` on proc macros under Miri · Issue #5101 · rust-lang/miri · GitHub](https://github.com/rust-lang/miri/issues/5101) (see older version of the initial post about the original report or else discussion will make little sense, sorry) > > This one boils down to the fact that there are separate `RUSTFLAGS`, `RUSTDOCFLAGS` and `MIRIFLAGS`, only two of which can be specified in `.cargo/config.toml`: > > - [Set MIRIFLAGS from .cargo/config.toml · Issue #2347 · rust-lang/miri · GitHub](https://github.com/rust-lang/miri/issues/2347) > - [Support `miriflags` in `[target]` configuration · Issue #17079 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/17079) > > If that wasn't bad enough, especially when cross-compilation is involved, host and build targets are not the same anymore, so even more configuration is necessary to configure both targets to have `-Znext-solver=globally` specified on them. > > So now I have this in my `.cargo/config.toml`: > > ```toml > # This wildcard allows to merge whatever user might have configured in their home folder > [target.'cfg(all())'] > rustflags = ["-Znext-solver=globally", "-Zmin-recursion-limit=256"] > rustdocflags = ["-Znext-solver=globally", "-Zmin-recursion-limit=256"] > > ``` > > **Plus** `MIRIFLAGS="-Znext-solver=globally -Zmin-recursion-limit=256"`. > > **Plus** `-Ztarget-applies-to-host -Zhost-config --config 'host.rustflags=["-Znext-solver=globally"]'` in CLI arguments. > > > **GitHub Actions quirk** > > > > Which depending on the context might force user to learn that `'` sometimes needs to be escaped as `'''` in GitHub Actions YAML definition, making it this: > > > > ```rust > > -Ztarget-applies-to-host -Zhost-config --config '''host.rustflags=["-Znext-solver=globally"]''' > > > > ``` > > Only then I can actually set it everywhere (that is once it actually works as expected, which I hope is going to be soon). > > Man, I just want to set `RUSTFLAGS="-Znext-solver=globally"` and be done with it 😭 > > This is very bad experience. * * * ## The solution Ideally, I'd like for `RUSTFLAGS` to become a global recursively applied environment variable. Meaning it applies to host target and build target, to both normal crates, build scripts, proc macros, rustdoc, Miri - everything. Something like `RUSTHOSTFLAGS` and `RUSTBUILDFLAGS` would then be a narrow equivalent of whatever `RUSTFLAGS` roughly means today. Though it might be impossible to do due to inherent breaking changes and lots of inherent complexity I'm not aware of. At least something like `RUSTGLOBALFLAGS`, which is an additive super-set of all possible `RUST*FLAGS`, would elegantly solve both of the motivating examples above. It would not be universal in a sense of covering all possible edge-cases, but I think it might just solve the majority of use cases users have for `RUSTFLAGS` in practice because the current state is honestly a mess. And only when user does things that actually require divergence between various flags they would have to learn that there is actually a family of different environment variables with a lot of tricky nuances in how they function. ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [July 10, 2026, 2:41am UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/2 "2026-07-10T02:41:00Z")
The real solution is to move all of these options to Cargo natively. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [July 10, 2026, 12:51pm UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/3 "2026-07-10T12:51:33Z")
Tracking replacement discussions at [Tracking Issue: Exposing RUSTFLAGS in cargo · Issue #12739 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/12739) ---
**Author:** ![nazar-pc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nazar-pc/32/11386_2.png) [@nazar-pc](https://internals.rust-lang.org/u/nazar-pc)\ **Post date:** [July 10, 2026, 12:57pm UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/4 "2026-07-10T12:57:52Z")
Cargo support is useful and will certainly be appreciated. It will also remove the need to use `RUSTFLAGS` in certain cases completely. That said, I'm not sure it is unrealistic to expect everything supported in `RUSTFLAGS` to be supported in Cargo directly. And as long as that is the case, I think my suggestion is still relevant. ---
**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\ **Post date:** [July 10, 2026, 4:04pm UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/5 "2026-07-10T16:04:19Z")
> [@nazar-pc](#): > > Ideally, I'd like for `RUSTFLAGS` to become a global recursively applied environment variable. Meaning it applies to host target and build target, to both normal crates, build scripts, proc macros, rustdoc, Miri - everything. Also see > > > The cargo documentation \`environment-variables.md\` says > \`\`\` > RUSTFLAGS - A space-…separated list of custom flags to pass to all compiler invocations that Cargo performs. In contrast with cargo rustc, this is useful for passing a flag to all compiler instances. > \`\`\` > This is wrong, unfortunately. The flag is not passed to all compiler instances: When cross-compiling (i.e., when \`--target\` is set), the flag is not passed to build scripts. It seems there is currently no way to pass anything to build scripts when \`--target\` is set, which clearly is a feature gap. Cargo should provide a way to set flags for build scripts even when cross-compiling. > > One may be tempted to set \`CARGO\_TARGET\_\\_RUSTFLAGS\` or \`target.\.rustflags\`, but that does not work either. > > Also see https://github.com/rust-lang/cargo/issues/9453, https://github.com/rust-lang/cargo/issues/9452. Unfortunately this would be a breaking change to do now... ---
**Author:** ![Vorpal](https://avatars.discourse-cdn.com/v4/letter/v/aca169/32.png) [@Vorpal](https://internals.rust-lang.org/u/Vorpal)\ **Post date:** [July 12, 2026, 5:45am UTC](https://internals.rust-lang.org/t/global-simple-universal-rustflags/24454/6 "2026-07-12T05:45:25Z")
Expecting everything to be in Cargo also doesn't help when other build systems are used (such as meson). This makes it very hard to globally configure options for package building on a Linux distro level. See [this Arch Linux issue](https://gitlab.archlinux.org/pacman/pacman/-/work_items/75) for some of the problems this cause.