Use stable Rust (tracking ticket for unstable features we use)

[geofft]

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 by kmalloc. PR Stabilize GlobalAlloc and #[global_allocator] rust-lang/rust#51241 from today stabilizes global_allocator and I think all the things under allocator_api that 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 Stabilize str::len, [T]::len and str::as_bytes as const fn rust-lang/rust#63770

[bjorn3]

#![feature(alloc)] has been stabilized in rust-lang/rust#59675.

[joshtriplett]

Do we still need const_fn, or do we have enough support in stable that it should work?

[alex]

@joshtriplett is there a change in "error[E0723]: trait bounds other than Sized on const fn parameters are unstable" since June?

[joshtriplett]

@alex Ah. No. Could we link to a more specific issue, if there is one, or file one if there isn't?

[alex]

I don't see an existing one.

[geofft]

I filed rust-lang/const-eval#56 asking about this. If you dig into the hidden comments in 57563, you see this:

The RFC doesn't have to talk about associated consts, because as you correctly inferred, associated consts are completely unproblematic. We could totally add trait bounds and allow you to use associated consts. The problem is that adding trait bounds would also give you access to associated functions, and then the question comes up whether you are allowed to call them. The RFC answers this question. Adding trait bounds to const fns needs to answer all questions about the items on the traits at once, we can't separate these out.

No, but once we allow trait bounds on the generic parameters of a function, and we allow you to call that without having a const impl for the trait, we lock in into that system and can't ever go back.

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 ?const type parameter, but if you can, that would resolve what we need.

[geofft]

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]

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]

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]

const_fn is no longer required. Down to 3 features (+ -Z build-std)

[ojeda]

the current syntax we're using is quite possibly not on the path to stabilization

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 sufficiently less ugly that even without a macro it's an improvement over the builder setup we have now

Seems quite clean to me! The kernel has seen way worse, to be honest.

[alex]

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.