Hey @James Munns, @Daniel Egger (cc @Josh Triplett), we've been discussing on the lang team some of what our top priority items ought to be (esp. around the upcoming deadline for Rust 2021 breakage) and I feel like it'd be useful to get the perspective of some folks from embedded. Embedded showed up as a pretty prominent target domain in the Rust Survey, and I'm curious to what extent you have a "wish list" of features there.
I'll add it to the agenda for our next meeting on Tuesday!
But I know Const Generics is going to be pretty high on the list :)
Especially in a heap-less use case, we often have users who need to provide variably sized backing buffers (static or otherwise) for things like queues. generic-array is widely used, at the moment.
The other one that will come up (my guess) is formatting handling.
Particularly, being able to swap out less dynamic formatters, or disable formatting on panic entirely, is a pretty big ask. Accidentally pulling in a panic handler can take a firmware image from 2K to 16K really fast, and that's a problem if you only have 16K or 32K (or 2K) of space.
Inline ASM is another big one, but I know that's underway
If anyone from the lang team is able to attend, our meeting is tomorrow at 20:00 CEST on matrix, details are here: https://github.com/rust-embedded/wg/issues/447
We have some old wish lists, but we're actually getting a bit sore at maintaining them, because they stay open for a very long time (or are a lot of issues to juggle), and we have little upward pressure to exert. I can link to the old lists later.
Given that dynamic format strings are never allowed (unlike C where you can override warnings and pass a dynamic format string to
printf-like functions), I'm wondering how hard it would be to teach Rust to leave out all formatting machinery that doesn't get called.
Yeah, the issue today is that:
panic()can invoke a lot of formatting code
it's not clear to me what the cost would be if we could accurately "pay for what we use".
I have... thoughts on the best steps forwards. but that's a personal axe to grind of mine.
Another one is stability guarantees around MMIO interactions, e.g. making sure there aren't spurious reads of things. Though that's another separate conversation.
I do think "pay for what we use" would help a great deal. If you only had the code to, say, format integers as hex, that's going to be a lot less than 16-32k.
It would be good to see! the post I linked has an associated repository, you likely could look at cargo-bloat/
size to see exactly how large each formatter actually is.
Adding a single panic was a +14K diff to the total binary size, but that's not "pay what you use".
Total cargo bloat report for the initial state of the repo: https://github.com/jamesmunns/tiny-nrf52/commit/04586a1620ed6a546ff6195aaf7d74e5c0b8e9bd#diff-191136ab3b249e2748060f86c435e260
File .text Size Crate Name 0.2% 9.7% 812B std <char as core::fmt::Debug>::fmt 0.2% 9.4% 790B std core::str::slice_error_fail 0.2% 8.7% 728B std core::fmt::Formatter::pad 0.2% 7.6% 634B [Unknown] main 0.1% 6.6% 550B std core::fmt::Formatter::pad_integral 0.1% 6.3% 530B std core::fmt::write 0.1% 5.9% 490B std core::slice::memchr::memchr 0.1% 4.3% 360B nrf52_hal_common <nrf52_hal_common::uarte::Error as core::fmt::Debug... 0.1% 4.3% 360B std core::fmt::num::<impl core::fmt::Debug for usize>::fmt
nrf52_hal_common::uarte::Error is a valueless enum, for example
main is nearly the whole program here, you get an idea of the relative sizes of formatting. As a note, this is before the changes to shrink unicode tables, though those constants are not shown in cargo bloat. (the 14K is 8K of .text and 6K of .rodata)
But, I'm picking on one specific topic.
I think you'll get very few hard blockers, a handful of reasonably complex items that would be QoL improvements (formatting, const generics, inline asm), and a bunch of "deep cuts" that are very specific requests.
Gotta run for now, thanks for reaching out @nikomatsakis!
That's really interesting, it's particularly useful to me to see the link to const generics, it'd be great to have a bit more details of the exact use cases (though I see you cited a few)
panic etc doesn't necessarily feel like a lang task but good to know it's such a footgun
I remember hearing about it but I don't know that I'd have expected it to make the list
Yeah, it would probably be good to clarify we are looking for a lang wishlist, rather than a compiler wishlist. If you have any other good examples of the kind of things you would like to see, that would probably be helpful for us to steer the conversation.
Also, reminder, the meeting is in about 1 hour (CC @nikomatsakis @Josh Triplett)
I unfortunately have a conflict at that time. :(
But I'd love to hear about the results, if you have minutes you can link to here.
Will do, I'll post the chat log shortly, and I'll write up a TLDR topic list. We brainstormed today, no prioritization yet.
Theres also a link to the whole chat log there, if you'd like additional context.
Lemme know if you have any questions by what we mean by any of the items. I hope that helps!