You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm in the process of adding a new tool to the Rust compiler but it's failing to build on CI. The root of the reason appears to be that this crate will automatically enable usage of the min_specialization feature on Nightly-looking Rust channels but the way that Rust is compiling crates makes it so the min_specialization feature isn't detected but this crate doesn't catch it. This is distinct from 76dd8d2 in that -Zallow-features is used as part of the rustc build but it's used in a non-default way. Overall the end-state is that this crate is causing a build failure as a transitive dependency of the tool I'm adding.
Given that context I'd like to pose a question, how would you feel about making usage of min_specialization require an opt-in from users rather than implicitly enabling it on supporting Nightly channels? That would look like a crate feature, a required RUSTFLAGS entry, or perhaps an environment variable at build time.
In addition to the rationale of working as part of rust-lang/rust I'd also offer the rationale that Nightly Rust features can theoretically break at any time and users using a Nightly toolchain may not expect breakage from crates because unstable features change. Requiring an explicit opt-in would help with that since then only those opting-in would be broken which would be expected.
I'm happy to make a PR for this as well, but wanted to gauge interest in such a change before doing so to make sure I wouldn't step on any toes.
The text was updated successfully, but these errors were encountered:
This commit switches away from implicitly enabling the `min_specialize`
Rust nightly feature whenever a Nightly compiler is used to instead
requiring an explicit opt-in with a new Cargo feature
`nightly-specialize`. The goal of this commit is to fixtkaitchuck#238 and has two
primary motivations:
1. In tkaitchuck#238 I'm trying to build something that depends on this crate as
part of the Rust bootstrap process but this crate fails to build due
to `min_specialize` not being allowed but a nightly compiler is in
use. This is due to the fact that the way `-Zallow-features` is
managed in the bootstrap is different than the standard Cargo way of
doing so.
2. This removes a failure mode where if one day the `min_specialize`
feature changes this crate won't break when built on nightly. Users
of Nightly compilers will be able to continue using this crate if the
feature was not explicitly opted-in to.
I'm in the process of adding a new tool to the Rust compiler but it's failing to build on CI. The root of the reason appears to be that this crate will automatically enable usage of the
min_specialization
feature on Nightly-looking Rust channels but the way that Rust is compiling crates makes it so themin_specialization
feature isn't detected but this crate doesn't catch it. This is distinct from 76dd8d2 in that-Zallow-features
is used as part of the rustc build but it's used in a non-default way. Overall the end-state is that this crate is causing a build failure as a transitive dependency of the tool I'm adding.Given that context I'd like to pose a question, how would you feel about making usage of
min_specialization
require an opt-in from users rather than implicitly enabling it on supporting Nightly channels? That would look like a crate feature, a requiredRUSTFLAGS
entry, or perhaps an environment variable at build time.In addition to the rationale of working as part of rust-lang/rust I'd also offer the rationale that Nightly Rust features can theoretically break at any time and users using a Nightly toolchain may not expect breakage from crates because unstable features change. Requiring an explicit opt-in would help with that since then only those opting-in would be broken which would be expected.
I'm happy to make a PR for this as well, but wanted to gauge interest in such a change before doing so to make sure I wouldn't step on any toes.
The text was updated successfully, but these errors were encountered: