Merge #380

380: Improve singleton!() macro r=adamgreig a=Rahix

This PR addresses two shortcomings of the `cortex_m::singleton!()` macro, which I raised in #364.  For review, I think it is best to look at the two commits implementing these changes individually.

I think this changeset should also be backported to `0.7.x` where it applies cleanly and which is also the place where I tested it.

### 1. Fix `singleton!()` sometimes ending up in `.data`
The static is always initialized to a "zero" value with `Option::None` which means it should end up in `.bss`.  However, if the enclosed type has a niche, `Option::None` can become a non-zero bitpattern which moves the whole singleton from `.bss` to `.data`.  This is especially problematic when storing large buffers in the `singleton!()` as this starts eating lots of flash space unnecessarily.

To prevent this, I switched to using an explicit boolean flag instead.  This is not quite as nice but at least there is no chance for the `singleton!()` to end up in `.data`...

For reference and as an example, the faulty behavior can be triggered with

```rust
cortex_m::singleton!(: Option<u32> = None)
```

(the inner option has a non-zero niche which the outer option will occupy)

### 2. Allow naming the `static`
Due to the static always being named `VAR` right now, all `singleton!()` instances end up having non-descriptive symbol names like `__cortex_m_rt_main::{{closure}}::VAR` which makes them hard to tell apart in a debugger or when looking at an objdump.

I added the ability to set an explicit name which end up becoming part of the symbol name.  This does not affect Rust code at all - the new name is not visible anywhere.  It works like this:

```rust
let value = singleton!(FOO_BUFFER: [u8; 1024] = [0u8; 1024]);
```

Of course the old syntax also still works and keeps the old behavior of calling the static `VAR`.

Fixes #364.

Co-authored-by: Rahix <rahix@rahix.de>

0 files changed, 0 insertions, 0 deletions