Constrain `CriticalSection` lifetimes

[YuhanLiin]

Related to https://github.com/rust-embedded/msp430/pull/9. bare-metal version 1.0 introduces a lifetime param on CriticalSection and requires that lifetime to be constrained so that it's not static. This change places such constraints on the CriticalSections provided by main and ISRs.

[cr1901]

Looks good to me, I'm accepting this as soon as I get clarification on the #[no_mangle] change.

[YuhanLiin]

The main and ISR signatures used to have the export_name attribute, which explicitly set the names of the signatures to main and #ident_s. My change makes those exported names into the names of the actual functions, and I use no_mangle to ensure that those function names actually get exported.

[cr1901]

When testing, I got an error like so:

   Compiling msp430g2553-quickstart v0.1.0 (C:\msys64\home\William\Projects\MSP430\msptest\msp430g2553-quickstart)
error[E0308]: mismatched types
  --> examples\blinky.rs:65:1
   |
65 | #[interrupt]
   | ^^^^^^^^^^^^
   | |
   | expected `!`, found `()`
   | implicitly returns `()` as its body has no tail or `return` expression
   |
   = note:   expected type `!`
           found unit type `()`
   = note: this error originates in the attribute macro `interrupt` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.
error: could not compile `msp430g2553-quickstart` due to previous error

It seems to be caused by the ! on line 300 in the macros crate:

#unsafety fn #hash<'a>(#cs_param) -> ! {

I'm not sure how to use quote! to "inject -> type if a type was provided on the interrupts signature, otherwise inject nothing". Can this be done using what syn::parse returns, or will I need to match on whether a return type was provided and generate two different pieces of code depending on the type?

[YuhanLiin]

Hold on interrupts shouldn't even return !. Before they just returned nothing. That's an oversight on my part.

[cr1901]

@YuhanLiin Well, it should be fine for now- I allow returning nothing or !. If this ends up being a bug, we can fix it later.

[YuhanLiin]

Are there any cases where returning ! from interrupts makes sense? That means the code gets stuck inside the interrupt right?

[cr1901]

cortex-m-rt uses ! for certain faults that you can't recover from. I don't remember offhand if MSP430 has a dedicated vector for e.g. "illegal memory access" or if it just goes back to NMI.

[YuhanLiin]

Well it doesn't hurt to have the option (and it's not a footgun since users have to write out the return type explicitly).