build: simplify use of nightly features #102
Conversation
Instead of check if a feature is already stable, simply enable them and allow the warning if the feature is already stable. This avoids the need of the hardcoding whether a feature has been stabilized at a given version. Signed-off-by: Gary Guo <gary@garyguo.net>
There was a problem hiding this comment.
I am not sure what's causing this change, perhaps just a new nightly?
There was a problem hiding this comment.
Yeah saw it in CI today too.
There was a problem hiding this comment.
I wanted to fix this tomorrow on main directly.
BennoLossin
left a comment
BennoLossin
left a comment
There was a problem hiding this comment.
I was about to write that we can't do this, since the crate is supposed to compile under stable Rust and that the CI should fail.
But looking at the code, you have replaced the *IS_STABLE cfgs with RUSTC_USE_FEATURE, which gets enabled on a nightly or RUSTC_BOOTSTRAP=1 compiler. I think it'd be important to put that in the commit message :)
Otherwise this looks sensible.
Do note that we do not sync the Cargo.toml file to the kernel, so if we put the lint levels there, we need some way to sync them. Either we add the Cargo.toml to the synchronized files and then make kbuild parse it, or we put the cfgs in lib.rs.
|
Also cc @antonio-hickey for these changes to how unstable features are enabled. That should simplify your PR a bit :) |
|
I deliberately put it inside Cargo.toml so it's not synced to the kernel, as kernel have enabled in globally inside Makefile |
|
I wanted to change that pin-init uses the global flags, to synchronize also the build flags between the kernel and here. |
|
I don't think it's really needed, as in the long term these flags should disappear when we bump MSRV |
|
I think it's better to build both versions with exactly the same lints levels. Otherwise I create a PR here and then notice when porting to the kernel that I missed something, requiring me to do the port again. |
|
I think it's true for lints in general, but for special ones like "stable_features", it's not an issue. |
Instead of check if a feature is already stable, simply enable them and allow the warning if the feature is already stable.
This avoids the need of the hardcoding whether a feature has been stabilized at a given version.
This should make the raw_ref_ops feature very easy to add.