Unstable features
Unstable features
Posted Mar 27, 2025 18:12 UTC (Thu) by comex (subscriber, #71521)In reply to: Quick notes by ojeda
Parent article: A process for handling Rust code in the core kernel
> There are only four unstable features needed by the kernel at this point, and that number will soon be zero, he said.
This isn’t right, is it? According to [1], there is only a small set of unstable features (indeed, four of them) allowed in *drivers*, but the core kernel crate still uses a large number of unstable features.
That said, stabilizing the features needed by Rust for Linux is one of the Rust Project’s “flagship goals” [2] [3], and I’ve seen active work on many of those features happening in parallel, so that number may go down more quickly than you might expect.
[1] https://rust-for-linux.com/unstable-features
[2] https://blog.rust-lang.org/2024/08/12/Project-goals.html
[3] https://rust-lang.github.io/rust-project-goals/
Posted Mar 27, 2025 18:55 UTC (Thu)
by ojeda (subscriber, #143370)
[Link] (1 responses)
No, but because the situation is actually better! :)
Even if one counts the `kernel` crate, it is essentially two language features left: `arbitrary_self_types` and `derive_coerce_pointee`. For other code, it is just the former.
The reason is that some of the features we need to list are meant to support older compilers that were released when they were not stable.
I will update the "Unstable features" page a bit to clarify this -- thanks!
This does not mean we may not use a new feature if it is really convenient and everyone is on board and so on. But we are finally very close to being able to say we don't use unstable Rust, language-wise.
Posted Mar 27, 2025 21:14 UTC (Thu)
by ojeda (subscriber, #143370)
[Link]
Unstable features
Unstable features