Passing unstable flags only on nightly toolchains

[P1n3appl3]

Problem

I sometimes enable unstable rustc features in my user level config.toml, such as the parallel frontend (-Zthreads).

This works fine when I'm using the nightly toolchain, but when I rustup default stable it causes builds to fail with error: the option Z is only accepted on the nightly compiler until I go comment that flag out in the config.

Proposed Solution

Adding a new target specifier for toolchain name or channel seems like the nicest solution, I'd love to be able to write:

[cfg.nightly]
rustflags = ["-Zthreads=0"]

And have that flag tacked on only when I'm using nightly. I think this works well with the existing behavior for targets and cfgs:

3. All matching target.<triple>.rustflags and target.<cfg>.rustflags config entries joined together.

Theoretically you could also introduce a cfg type for the current toolchain so you could write:

[target.'cfg(toolchain = "nightly")']
rustflags = ["-Zthreads=0"]

... but I'm not sure that it makes sense given that code generally isn't aware of what toolchain it's built under, not to mention that adding a new cfg type seems like a bigger change than is necessary.

Notes

This question was asked on the rust discord around a year ago (by @RocketPrinter) and @danielhenrymantilla suggested the following workaround:

Something you could do is setup a rustc_wrapper.sh script which would do something along the following lines:

#!/bin/sh
if "$1" -V | grep -q nightly; then
   "$@" -Z ...
else
   "$@"
fi

I'm currently using this, but it feels gross to rely on the path of the running rustc and in the long term it'd be nice to not need a wrapper.

[epage]

We do have

[target.<cfg>]
runner = "…"            # wrapper to run executables
rustflags = ["…", "…"]  # custom flags for `rustc`

There is an approved RFC for cfg(version) and cfg(accessible) but that doesn't cover release channels. These are generally geared around detecting what can be used for community libraries. For nightlies, a feature is tied to a range of them so it can't be used for that case. If you set aside dependents and only focus on development, assumptions like in your proposal can be made.

A user could emulate this by manually passing in --cfg nightly.

For myself, I would want the exploration of a toolchain = nightly to be generalized to rustc and Cargo before considering whether we'd want to do a Cargo-only solution.

Another part to this is what about Cargo unstable features. cfg tables are generally evaluated as part of compilation and I assume have to deal with host/target settings. Doing it also in a way to evaluate unstable features might be a bit much.

[weihanglo]

but that doesn't cover release channels.

I didn't follow the RFC too close, though channels is a concept in rustup. Not sure if there is a plan for cargo/rustc to support it natively.

[joseluis]

I step into this issue after trying to pass --generate-link-to-definition in nightly without losing the ability to compile docs in stable.

I found a temporary work-around only because config-include is still unstable, so files can only be included when using nightly.

.cargo/config.toml:

include = "nightly.toml"

[unstable]
unstable-options = true
config-include = true

.cargo/nightly.toml:

[build]
rustdocflags = ["-Zunstable-options", "--generate-link-to-definition"]

[TorstenSchmitz]

The Wasm ABI transition presents another pressing need for this.

[target.'cfg(toolchain = nightly)']
rustflags = ["-Zc-wasm-abi=spec"]

This option is perma-unstable and will be done away with in the future,
however to support both stable and nightly builds currently it has to be specified on nightly and left out on stable.

The cfg(version) RFC doesn't fix it since it can only let you add flags to stable or beta versions.
The flag will be removed soon™, but for future shenanigans like it we need something like [cfg(nightly_version>= X && nightly_version<= Y)]

or

[cfg(version>= X-nightly && version<= Y-nightly)]