Prioritise 2019 wishlist items for rust-lang

[adamgreig]

Many of the items on the 2019 wishlist (#256) will require work in rust-lang repositories and by rust-lang teams. The WG should be able to present rust-lang members with a clear list of what we'd like, with each item prioritised, and well described and motivated. We can then further work out which to work on and in what order depending on how much work they'll take.

We've already identified which wishlist items require rust-lang work in the spreadsheet; I suggest we sort them by votes initially, then try to narrow it down to around 10-15 items that seem feasible, would have a decent impact on embedded users, and which we can then work with rust-lang to get implemented in 2019.

[thejpster]

So, at work, we'd do this by getting a bunch of people in a room, writing the items on post it notes and then adding them a whiteboard one by one in a sort of Insertion Sort.

I'm afraid I don't know how to translate that to a comment thread, but maybe we just need to jump on IRC for an hour with a Dropbox document or something?

[japaric]

@thejpster I like the idea and I agree that we should have a dedicated meeting to dig through these requests. We can use the next meeting to pick a date for such meeting and the format of the discussion.

[japaric]

I've added a filter view to the spreadsheet to visualize only the rust requests and to sort them by votes. (Note that there's some age bias: older items have been seen by more people so they tend to have more votes). The top 15 as of 2018-12-21 are:

1. std-aware Cargo / Xargo in Cargo (56 58 votes)
2. math support in core
3. std::io in libcore/liballoc
4. Support for AVR (+1)
5. Stabilize const fn-s that have trait bounds, e.g. const fn new() -> Mutex where T: Send. (-1)
6. fix Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs rust-lang/cargo#5730 - "Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs"
7. Stabilize core::mem::MaybeUninit
8. Fix Generic associated consts can't currently be used to parameterize fixed array lengths rust-lang/rust#42863 - "Generic associated consts can't currently be used to parameterize fixed array lengths"
9. Improve crates.io or create separate site for no_std crates
10. Stabilize async/await (and all needed underlying machinery) (+1)
11. Stabilize RFC 2282 - "Cargo profile dependencies" AKA profile-overrides (-1)
12. Fix so infinite loops (loop {}) does not need an atomic compiler fence to not be optimized into an abort instruction
13. ability to assert within a const fn context, with a compilation error if the assertion fails at compile time and a panic if the assertion fails at runtime.
14. Language support for types with storage size of less than 1 byte
15. Thumb intrinsics (10 votes)

There are other 17 items which are not in the top 15. Is there any item that you feel is high impact but has been left out the top 15?

EDIT: Updated on 2019-01-09

[japaric]

I have updated the top 15 list in my previous comment using the newest data. A few items have switched places but the top 15 remains the same.

On the next meeting (#291) will discuss and prioritize these requests synchronously. If you cannot make to the meeting please leave your thoughts in this thread and we'll include them in the discussion.

[andre-richter]

Following up on #270 (comment), cortex-a has the following rust-lang related change on the radar: #230 (Add a rust-std component for aarch64-unknown-none-(nohf))

Adding hard-float and no hard-float rust-std components will allow for kernel (no-hf) and bare-metal (hf might be wanted here in some cases) development on aarch64 targets without relying on xargo.

[jonas-schievink]

It is now one year later (apparently!). I'll update the checklist from above, then close. Or do we want to blog about this?

• std-aware Cargo / Xargo in Cargo (56 58 votes)

A proof of concept of this has landed on nightly. cargo build -Z build-std=core.

• math support in core

• std::io in libcore/liballoc

• Support for AVR (+1)

• Stabilize const fn-s that have trait bounds, e.g. const fn new() -> Mutex where T: Send. (-1)

• fix rust-lang/cargo#5730 - "Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs"

Not much happened here I'm afraid.

• Stabilize core::mem::MaybeUninit

✔️

• Fix rust-lang/rust#42863 - "Generic associated consts can't currently be used to parameterize fixed array lengths"

This is blocked on lazy normalization, which is being worked on in rust-lang/rust#67890

• Improve crates.io or create separate site for no_std crates

Nothing happened here (does the crates.io team know how bad the shortcomings are for embedded?)

• Stabilize async/await (and all needed underlying machinery) (+1)

✔️

• Stabilize RFC 2282 - "Cargo profile dependencies" AKA profile-overrides (-1)

✔️ (stabilized in rust-lang/cargo#7591 for Rust 1.41)

• Fix so infinite loops (loop {}) does not need an atomic compiler fence to not be optimized into an abort instruction

Some work on this was done. The compiler can now insert the LLVM sideeffect intrinsic when passing -Z insert-sideeffect. Not sure what the next step is.

• ability to assert within a const fn context, with a compilation error if the assertion fails at compile time and a panic if the assertion fails at runtime.

This now works, if you enable a whopping 3 feature gates (#![feature(const_fn, const_panic, const_if_match)]). Significant progress on const_if_match was made this year to enable this.

• Language support for types with storage size of less than 1 byte

Not sure about this (from #256 (comment)). Is this different from C bitfields?

• Thumb intrinsics (10 votes)

No progress.

[thejpster]

Yeah, we should do a 2019 round-up blog. There's good progress here, but also pain points we should continue to highlight

…