build: simplify use of nightly features

[nbdd0121]

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.

[BennoLossin]

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.

[BennoLossin]

Also cc @antonio-hickey for these changes to how unstable features are enabled. That should simplify your PR a bit :)

[nbdd0121]

I deliberately put it inside Cargo.toml so it's not synced to the kernel, as kernel have enabled in globally inside Makefile

[BennoLossin]

I wanted to change that pin-init uses the global flags, to synchronize also the build flags between the kernel and here.

[nbdd0121]

I don't think it's really needed, as in the long term these flags should disappear when we bump MSRV

[BennoLossin]

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.

[nbdd0121]

I think it's true for lints in general, but for special ones like "stable_features", it's not an issue.

[BennoLossin]

I have some suggestions for the commit message:

We use some features that are already stable in later versions of Rust,
but only available as unstable features in older Rust versions that the
kernel needs to support.

Instead of checking if a feature is already stable, simply enable them
and allow the warning if the feature is already stable. This avoids the
need of hardcoding whether a feature has been stabilized at a given
version.

`#[feature(...)]` is used when cfg `USE_RUSTC_FEATURES` is enabled. The
build script automatically does this when a nightly compiler is detected
or `RUSTC_BOOTSTRAP` is set.

As a diff to your current one:

-We use some features that are already stable in later version of Rust, but
-only available as unstable features in older Rust versions that the kernel
-needs to support.
+We use some features that are already stable in later versions of Rust,
+but only available as unstable features in older Rust versions that the
+kernel needs to support.
 
-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.
+Instead of checking if a feature is already stable, simply enable them
+and allow the warning if the feature is already stable. This avoids the
+need of hardcoding whether a feature has been stabilized at a given
+version.
 
-`#[feature(...)]` is used when cfg `USE_RUSTC_FEATURES` is enabled, which
-will be enabled when nightly compiler is detected or `RUSTC_BOOTSTRAP` is
-detected.
+`#[feature(...)]` is used when cfg `USE_RUSTC_FEATURES` is enabled. The
+build script automatically does this when a nightly compiler is detected
+or `RUSTC_BOOTSTRAP` is set.