Apparently serde_derive only calls next_key or next_key_seed however many times as there are elements in the tuple. The SeqAccess impl has no way to know beforehand that it will only be called that many times, so if it is deserializing e.g. a JSON array it needs to preemptively peek for ] every time next_element_seed is called in order to not leave garbage on the input. I think this should at leas

Is there a description somewhere, in the rust docs, rfc, something..? that explains what exactly is necessary to do a cross build, or do I have to reverse engineer sysroot.rs?

When adding a comment to the app macro as such:

/// Some text <- this causes the error
#[app(device = stm32f4xx_hal::stm32, peripherals = true)]
const APP: () = {
    #[init]
    fn init(cx: init::Context) {}
};

Gives the error:

error: expected `const`

error: aborting due to previous error

It would be nice to have a little more fleshed out info about the recommended ways to share data between interrupt handlers and the main program. With the addition of Qxx, I assume that this is to be preferred, but its size limitation makes it not always applicable if items come in bursts and handling them can take a while.

Using Queue in such a context still requires static mut unsafe, and

NVIC::enable() was deprecated with the following warning.

WARNING This method is a soundness hole in the API; it should actually be an unsafe function. Use NVIC::unmask which has the right unsafety.

https://docs.rs/stm32f3xx-hal/0.3.0/stm32f3xx_hal/stm32/struct.NVIC.html#method.enable

NVIC::unmask() has the following documentation.

This function is unsafe because it can break m

@jamesmunns and I had a discussion on Matrix about the current defaults that leave HardFault_ and DefaultHander_ implemented as infinite loops.
This should most likely be replaced with panic in the default case to help the implementors detect issues and if nothing is done the panic crate takes care of the default course of action.
This might increase code size a bit, but for those that do

Currently the link layer will abort the connection when it does not receive the initial connect event:

https://github.com/jonas-schievink/rubble/blob/0c219f5fd1ef24cc6ca6f6e1edb02556e5fdd64f/rubble/src/link/connection.rs#L338-L345

This shouldn't happen. Instead, we should do what the comment suggests (and check it against the spec).

The effect of this bug is that establishing a connection

Make generation of the DSDLSignature attribute configurable just as the generation of the data type signature is configurable.

The main difference is that DSDLSignature should be generated by default.

This means that the flag for the binary need to be in negative form.

Reexport memory barrier funcs from rust-lang/stdarch#557