Implement new InterruptNumber trait from next cortex-m release

[therealprof]

This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M
and thus changes CI and svd2rust-regress accordingly.

Replaces #455

Signed-off-by: Daniel Egger [email protected]

[rust-highfive]

r? @adamgreig

(rust_highfive has picked a reviewer for you, use r? to override)

[adamgreig]

This LGTM to me, except I don't understand why we were using cortex_m_rt::interrupt before anyway.

[therealprof]

I have no idea why we're not getting random errors in for different vendors. Need to investigate after cooking...

[therealprof]

@adamgreig If we're happy with this we'll only need the cortex-m release to finalize this PR.

[adamgreig]

I think this was here to ensure the svd2rust generated PAC exports an interrupt macro, since the cortex-m-rt documentation says you should use interrupt from your PAC and not from c-m-rt. So, I think we should keep the pub use cortex_m_rt::interrupt, but we don't need to pub use cortex_m::interrupt::InterruptNumber at all, since the impl writes the full path anyway.

[adamgreig]

Looks good. I think we'll have to try it out a bit with cortex-m and PACs to be sure it's working as we expect but PR looks fine to me. Could you add a CHANGELOG entry?

[therealprof]

@adamgreig I've updated the PR to use the release and added a CHANGELOG. I also ran svd2rust-regress locally but I haven't tried adapting a HAL impl yet.

[adamgreig]

bors merge

[bors]

Build succeeded:

• ci-linux (stable, rustfmt, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Atmel, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Freescale, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Holtek, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Nordic, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Nuvoton, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, NXP, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, RISC-V, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, SiliconLabs, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Spansion, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, STMicro, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, Toshiba, x86_64-unknown-linux-gnu, linux)
• ci-linux (1.37.0, Nordic, x86_64-unknown-linux-gnu, linux)
• ci-linux (stable, x86_64-apple-darwin, osx)
• ci-linux (stable, x86_64-pc-windows-msvc, windows)
• ci-linux (stable, Fujitsu, x86_64-unknown-linux-gnu, linux)

[Rahix]

This change breaks the build for avr-device. The problem is that you modified the else branch which is for everything but msp430 ...

I suppose this code needs to be refactored such that this line is only emitted for cortex-m. I would assume other platforms (like riscv) will also run into the same issue.

Cc: @trembel

[therealprof]

@Rahix Thanks for noticing. Indeed we has some discussion in #455 about other architectures and the approach to be taken there.

Since this doesn't break RISC-V in CI, this would imply that either it doesn't break or that it is not exercised properly.

AVR is not even tested in CI which would be a good first thing to add.

[Rahix]

Since this doesn't break RISC-V in CI, this would imply that either it doesn't break or that it is not exercised properly.

Hmm, from reading the code in interrupt.rs I cannot tell how RISC-V manages to evade this problem (unless all tested SVD files contain no interrupts at all which I would assume is not the case). Would need another closer look ...

AVR is not even tested in CI which would be a good first thing to add.

I can look into adding that. For AVR, the vendor files are in a format called ATDF which we first convert to SVD using a small utility called atdf2svd. I suppose I should upload a pre-generated SVD somewhere and reference that for the CI tests?