-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Probing for nightly #28
Comments
I'm open to it. We could add some nightly detection in the version part of the API (and dev is the equivalent), but I would also want to see some principled feature probing. There could be methods to set global
I think there are other version-detection build crates that already deal with nightly, so that cat is out of the bag... But I do agree that this should be used carefully, if at all. |
Per-probe features seems excesive. Here's the API I'm imagining.
which adds #![feature(example_feature)] at the start of all probes as you described. But setting features fails on stable and beta, so consumers of this api must probe which channel they're on enum Channel {
Stable,
Beta,
Nightly,
}
autocfg::probe_channel(&self) -> Channel Alternatively, we cold have an api that looks something like autocfg::set_feature(&mut self, &str feature)
autocfg::probe_expression(&self, expr: &str) -> Result<bool, InvalidChannelError> With no explicit |
As a case study, it would be nice to switch https://github.com/Xudong-Huang/generator-rs from rustc_version to autocfg. As an option for stateless API, we coud consider this: impl AutoCfg {
// Checks that `#[features(my-feature)]` doesn't get "you need nightly" / "unknown feature" error
pub fn probe_features(&self, features: &[str]) -> bool;
// Checks that feature *exists* and that it work as expected (by compiling expr with features enabled)
pub fn probe_features_with(&self, features &[str], expr: &str) -> bool;
} |
Would it be a good idea to allow consumers of autocfg to probe if their compiler is nightly or not? This could be used in instances where a crate uses a nightly api, but it is not essential to the functioning of the crate. For example, a nightly-only api might make a function faster, or enable more functionality. Allowing probing if the compiler is nightly could allow a crate to automatically enable a "nightly" feature, so nightly users don't have to manually enable the feature. Alternatively crates that require nightly (like the popular rocket not so long ago) could give custom error messages with links to explanations of why they need nightly.
The argument against such an api is that it could be too magic and it could be bad for crater i.e. did nightly break the code or was the code always broken with the nightly feature enabled.
The text was updated successfully, but these errors were encountered: