Meeting 2025-08-19

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• IRC/Matrix logs

[jamesmunns]

We've been asked by the build-std team to review their RFC. It is a fairly lengthy read, but very relevant to embedded folks.

We've been asked to limit direct feedback to members of the WG for now, but we may want to curate any community feedback here (or in a tracking issue) if necessary.

[jamesmunns]

Note from me, I have a scheduling conflict for the next meeting, I may not be able to attend the first 30m or so. I'll join as soon as I am able.

[diondokter]

I do like the proposals in general. Especially stage-1b where you can specify things in Cargo.toml.

One opportunity I don't see mentioned (though it is a lot of text and I might have missed it) is the ability to remove the #![no_std] attribute entirely (in e.g. edition 2027). I think this would streamline the whole std management and make it a proper system instead of a hack.

You'd have to be able to turn off the std somehow, which may just be std = { optional = true } in the Cargo.toml.
That's still a little weird, but I think less weird than #![no_std] if you try to look at it as though you're a new Rust user.

[kaspar030]

hmmm, removing the cli flag (-Zbuild-std) because poor ux doesn't make much sense to me.

Ariel OS is building for a dozen rustc targets from a single workspace, only a subset of the builds for a subset of the targets need build-std. So the cargo configuration is not the right place to put this IMO. Probably this can still be enabled via CARGO_something, e.g., CARGO_TARGET_<triple>_BUILD_STD=foo, or cargo --config target.<triple>.build-std=foo, but then includes the redundant and awkward triple info and/or confusing transformation from the example configuration settings to the environment variable.

IMO for embedded, the cargo configuration as place for build-std config is too static.

[jonathanpallant]

I do like the proposals in general. Especially stage-1b where you can specify things in Cargo.toml.

One opportunity I don't see mentioned (though it is a lot of text and I might have missed it) is the ability to remove the #![no_std] attribute entirely (in e.g. edition 2027). I think this would streamline the whole std management and make it a proper system instead of a hack.

You'd have to be able to turn off the std somehow, which may just be std = { optional = true } in the Cargo.toml. That's still a little weird, but I think less weird than #![no_std] if you try to look at it as though you're a new Rust user.

See https://github.com/davidtwco/rfcs/blob/build-std-iteration-2/text/0000-build-std/4-stage-1a.md#why-not-replace-no_std-as-the-source-of-truth-for-whether-a-crate-depends-on-std

[sgued]

Release of heapless 0.9.1

Thanks edit @zeenix and I joining the libs team heapless is ready for a 0.9.1 release. I think we can release it this evening.

[jamesmunns]

Ergot - Call for Experimentation

I wrote up a "call for experimentation" for Ergot, my messaging library. Check it out here: jamesmunns/ergot#76, I would love to have more embedded rust folks try it out, especially if you're someone who has/plans to hand roll some kind of communication based on postcard :D

[adamgreig]

• svd2rust 0.37 was released
• Add mutex-traits-based implementations of SpiDevice and I2c embedded-hal#683
• Add a macro to make initialization easier embedded-alloc#103

[jamesmunns]

I can look into the rust-embedded/embedded-hal#683 impl!