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.