Impact on build scripts that invoke rustc

[jdm]

While experimenting with how to build Servo for targets where libstd is not available through rustup, I've been exploring whether the new -Z build-std is enough. This has led me to discover rust-lang/cargo#7501 (via cuviper/autocfg#12), so I want to make sure that the people working on this feature consider the interaction of it with build scripts that need to perform their own rustc invocations.

[epage]

In rust-lang/cargo#11244, I questioned whether we should go out of our way to support build probes or if we should instead direct people to

• cfg_accessible
• crates providing opt-ins for nightly features.

[epage]

This is also being discussed at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/-Zbuild-std.20with.20build.20scripts.20that.20invoke.20rustc

[epage]

Closing for similar reason as rust-lang/cargo#11244

We talked about this in today's cargo meeting. The use cases seem to be focused on build probes. We are not inclined to add features specifically for build probes at this time but would instead encourage use of

* `cfg(accessible)` and `cfg(version)` where possible (interest from t-lang to stabilize, just needs a champion to check it over and drive stabilization)

* `features` everywhere else (or maybe even [global features](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618)), including enabling of nightly features

While cfg(accessible), cfg(version), and global features would involve MSRV bumps, I suggest considering whether the soon-to-stabilize MSRV-aware resolver might be sufficient to re-evaluate an MSRV policy in light of a feature like this. For a foundational package, one could bump minor and leave room for critical patches of old versions while allowing new versions to use these features.