perlindgren

The CI problem has been resolved in an uggly hackish manner. As v6 and v7 differ in implementation expected output may differ. However for simplicity the CI is designed with...

So I think soundness here needs to be revisited. - Both NMI handlers and panic! (as a potential binding to an RTFM task) occurs due to an error, so we...

Attribute evalution plays a key role here, as far as I know we cannot evaluate the `cfg`s at compile time (inside the proc-macro), thus we cannot take the cfgs into...

Yes, in some special cases, where the analysis and codegen does not depend on the evaluation of the attribute. But its hard to foresee what kind of problems might arise...

No decision taken yet. Would the approach suggested by @little-arhat be sufficient to support you use case @franeklubi ? /Per

Hi. Its been a while since looking at this, the point would be just `cfg` to bind different handlers, not making tasks/resourrces optional or?

IMHO, we have two levels of abstraction, cortex-m/cortex-m-rt, which provides the low level HW interaction, and we have RTFM as the lowest level user facing API. So there is no...

This will be solved by : https://github.com/rtic-rs/cortex-m-rtic/pull/623

I think the main concern here is that it exposes the implementation details. I don't think it would be unsound to expose though. The underlying problem seems to be related...

Yea, I saw this problem as well, I thought my `rust-analyzer` was acting up, but it seems to be a more fundamental problem. In general rust analyzer is now better...