Add a macro to make initialization easier

[JalonWong]

No description provided.

[zeenix]

Sounds good to me, thanks! Just a bit of nitpicks and it should be mergable.

[JalonWong]

@zeenix I have made improvements based on the suggestions, and I added a assert!($size > 0); in the macro. Is it appropriate?

[zeenix]

LGTM, thanks!

[zeenix]

@JalonWong I'll merge soon but I want to first give others a chance to have a look.

CC @adamgreig @sgued

[adamgreig]

My only thought is that people are likely to want to configure where the backing store for the heap is located in memory using link_section. If the assert!() wasn't there, you could put #[unsafe(link_section=".sram2")] before the init!() macro call; I'm not sure what's most elegant otherwise though:

• add an optional macro argument for link section? helps for this case, but maybe people will want other attributes (though I think link section is the main one)
• move the assert later so people can decorate the static mut with whatever attributes they want? I guess it works but it's kind of ugly and unclear when reading the code what it applies to
• leave it as-is, and if someone wants to specify the linker section they can just write the macro code out by hand instead

[zeenix]

• add an optional macro argument for link section? helps for this case, but maybe people will want other attributes (though I think link section is the main one)
• leave it as-is, and if someone wants to specify the linker section they can just write the macro code out by hand instead

How about a combination of these two: we add the optional argument for the linker section and if people need to add other attributes, they just don't use the macro?

[JalonWong]

@zeenix @adamgreig If someone want to use link_section I think they just don't use the macro. I leave the previous example in the README.

[JalonWong]

@sgued @zeenix I found out that it's very easy to add once in the init(), because critical_section is already used in it. I just added a bool member variable. This keeps the macro very simple, I also remove the unsafe in the macro, it works fine.

Do you think that this is a better solution?

[zeenix]

With the assertions in place now, these are no longer a safety issue but rather just panic scenarios, so I'd change the heading here from Safety to Panics and update the wording of the section.

[JalonWong]

I'm not sure how to express it. Could you provide some content?

[zeenix]

Same comment on these.

[zeenix]

So my question was that why do we need a separate boolean field with it's own mutex when could use core::cell::OnceCell? We can bump the MSRV if that's an issue here.

[JalonWong]

I use Mutex because it's a hint that we should use it in a critical section. Since the Mutex of critical_section is basically an UnsafeCell, I think it's not bad.
And because Sync is not implemented for OnceCell, using it directly might not be safe enough.