Require an opt-in for enabling `min_specialization` rustc feature

[alexcrichton]

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.

[tkaitchuck]

Are you saying that you have a build of the compiler where: version_check::supports_feature("specialize") returns true, but where the feature is not actually supported? Is that a bug in the compiler, in version_check, or an oddity due to running with a custom build of the compiler? Is there a different way to detect this that would not give incorrect results?

Longer term, I am planning a 1.0 release of the crate which will remove all specialization. The current design of the feature makes code using it way too complex and verbose to be practically maintainable. My plan to avoid the performance hit is just to require the application to invoke different methods to instantiate the Builder because in general the type of the key of a map is almost always known at the instantiation site.

Obviously a new version won't affect exiting packages which depend on existing versions of the crate. Do you need a work around for existing package versions?

[alexcrichton]

More-or-less that's the situation yeah. When the build script is invoked in the Rust build system the RUSTFLAGS setting doesn't 100% reflect the flags the crate is going to build with. The build script thinks it has access to all nightly features but the crate itself is compiled with an extra -Zallow-features flag which doesn't actually list the feature. This is due to build-system-of-rust-itself shenanigans and I believe is difficult to change.

As for the time being no workaround is urgent as things have already landed in rust-lang/rust#126967 where extra features were allowed for specialization here. Due to the tool not actually needing specialization or performance wins it would ideally be best to remove the need for specialization to avoid unnecessary dependencies.

[tkaitchuck]

Would this fix the detection issue? SergioBenitez/version_check#22

[alexcrichton]

Unfortunately I think not, not because that PR doesn't work though. It's that the compiler flags the build scripts sees are different than the crate itself due to the way the bootstrap build works