This repository was archived by the owner on Mar 7, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 7, 2021. It is now read-only.
Use stable Rust (tracking ticket for unstable features we use) #41
Description
More ambitious than #37, and won't be possible for a long while yet. Here's what we use currently:
-
#![feature(alloc)]: to be able to use liballoc (Box,String,Vec, etc.). Tracking issue for location of facade crates rust-lang/rust#27783 I think, though I don't see any recent progress about liballoc specifically. (But as noted in Make it possible to write modules in stable Rust #37 most things we need are re-exported through libstd, so maybe we can advocate for pushing the unstable attribute down to the things that aren't re-exported?) -
#![feature(global_allocator)]: to be able to define an allocator backed bykmalloc. PR Stabilize GlobalAlloc and #[global_allocator] rust-lang/rust#51241 from today stabilizesglobal_allocatorand I think all the things underallocator_apithat we use. (Also, as part of its work, it pushes down some of liballoc's wide instability to particular modules; we might want to advocate to do more of that to stabilize the re-exported parts of liballoc to solve the previous one.) -
#![feature(allocator_api)]: See Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540 -
#![feature(lang_items)]for#[lang = "oom"]: See Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540 -
#![feature(use_extern_macros)]: I think we don't need it, Remove#![feature(use_extern_macros)]#40. -
#![feature(panic_implementation)]: for#[panic_implementation] -
#![feature(alloc_error_handler)]: See either Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540 or RFC: Existential types with external definition rust-lang/rfcs#2492. -
#[feaure(const_str_as_bytes)]: See Stabilizestr::len,[T]::lenandstr::as_bytesas const fn rust-lang/rust#63770
Activity
bjorn3 commentedon Apr 30, 2019
#![feature(alloc)]has been stabilized in rust-lang/rust#59675.joshtriplett commentedon Aug 28, 2020
Do we still need
const_fn, or do we have enough support in stable that it should work?alex commentedon Aug 28, 2020
@joshtriplett is there a change in "error[E0723]: trait bounds other than
Sizedon const fn parameters are unstable" since June?joshtriplett commentedon Aug 28, 2020
@alex Ah. No. Could we link to a more specific issue, if there is one, or file one if there isn't?
alex commentedon Aug 28, 2020
I don't see an existing one.
geofft commentedon Aug 29, 2020
I filed rust-lang/const-eval#56 asking about this. If you dig into the hidden comments in 57563, you see this:
We want this for function pointers, which I think is basically equivalent to associated consts.
"The RFC" there is rust-lang/rfcs#2632, which is open but apparently being provisionally implemented to see how it goes. It seems the proposal is to add a
<T: ?const Trait>syntax, which means "I'm not calling any functions from T." It's not totally obvious to me whether you can get to function pointers / associated consts of a?consttype parameter, but if you can, that would resolve what we need.geofft commentedon Aug 29, 2020
Oh hey, tock/tock#1654 looks very similar to this issue except they've got a whole kernel going. I think it's promising that they're almost stable, and const fn is one of their biggest open questions (I think they need the same thing that we do.)
cc @ojeda since we were talking about what unstable features we might need - this seems promising that we could get to stable pretty quickly!
ojeda commentedon Aug 30, 2020
Indeed, the discussion is similar and it is promising. Getting Rust into the kernel can be a strong argument for Rust to stabilize whatever is missing and, conversely, getting Rust into mainline and iterating over there will make us know what bits we may end up really needing and which ones we could circumvent if needed, like it seems to have happened with the Tock project as well.
geofft commentedon Aug 30, 2020
Discussion in the issue I filed implies that the current syntax we're using is quite possibly not on the path to stabilization, so it might be worth figuring out how to avoid it.
After thinking too hard about this, I came up with a weird solution that avoids
#[feature(const_fn)]- see the last paragraph of my comment rust-lang/const-eval#56 (comment).We'd probably want to wrap that up inside a macro to make it a little less ugly to use.
EDIT: Made some tweaks to the proposed solution based on @alex's suggestions. The playground link in the most recent version of my comment seems sufficiently less ugly that even without a macro it's an improvement over the builder setup we have now.
alex commentedon Aug 30, 2020
const_fnis no longer required. Down to 3 features (+-Z build-std)ojeda commentedon Aug 30, 2020
Yeah, that is the kind of thing I was trying to point out in the LPC hackroom... In this kind of things there is always a chance that, in practice, we may not get something for one reason or another (which is fine!).
On the other hand, if we believe a much better alternative will end up being stabilized soon (e.g. within a year), then I wouldn't worry much to avoid it for the moment.
Seems quite clean to me! The kernel has seen way worse, to be honest.
alex commentedon Sep 6, 2020
abc9791 has further reduced the need for nightly -- at this point the only things we need are for the allocator API and
-Zbuild-std.Strictly speaking if one were motivated, I think they could make this work without those.
suhr commentedon Sep 25, 2020
Could you describe a way to get rid of
-Zbuild-std?