Miri Experiment

[bjoernQ]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

This isn't intended to get merged (especially not as is)! It's just for exploring and discussing if and how we could make use of MIRI

• apparently unsafe { &*Self::PTR } is not ok for register blocks ( Const validation rejects references that might be dangling (but could actually be valid at run-time) rust-lang/rust#63197 (comment) ) - the first commit here is just to not already fail during compilation
• We don't have MIRI for Xtensa - so just using our RV targets here
• I admit that single test added here is not useful - I can imagine MIRI could make sense to check some other things, however. Probably we would have to make use of #[cfg(miri)] to make interesting functions available

Testing

n/a

[bugadani]

Wait, this compiles? 👀

[MabezDev]

This is interesting! Thanks for looking in to this!

I'm curious if we can just run all (or a subset) of our HIL tests with miri enabled? That would feel a bit more useful than writing seperate miri specific tests, I think. I've never actually tested any of my projects with MIRI though, so I'm not sure how it's typically used.

[bjoernQ]

I thought about how we could test usual driver code - one thing that might be possible would be to have a forked svd2rust which produces mock-PACs which Miri won't hate (it definitely hates writing / reading to / from random addresses) - and also our drivers expect something to happen when we write to the hw-registers

I think that could work - I am just not very sure if it's a good deal in terms of effort vs benefit - but would definitely be fun to explore