Bump the MSRV to 1.67, check the defmt feature in MSRV check
#798
Conversation
It was because their own policy is "latest stable", and I didn't want to specify anything older, as a sort of escape hatch. If the dependencies need to be updated for any reason, the MSRV may or may not change and I guess tracking that just for an optional feature might be more annoying than the vague spec. |
| It should be noted that targeting the Xtensa ISA currently requires the use of the [esp-rs/rust] compiler fork. Our recommend method of installation is [espup]. | ||
|
|
||
| RISC-V is officially supported by the official Rust compiler. | ||
| When targetting the RISC-V architecture, it is necessary to set `RUSTC_BOOTSTRAP=1` in order to build with a previous stable release; this is not required when targeting Xtensa. |
There was a problem hiding this comment.
While it already says it, maybe we could explicitly say RUSTC_BOOTSTRAP is not needed when using a nightly compiler?
There was a problem hiding this comment.
Thanks for the suggestion. Going to just merge this for now to get it in, but I'll make a note to clarify that (I have some more README updates I'd like to make at some point, so will take care of this soon-ish)
…-rs#798) * Bump MSRV to 1.67, check with `defmt` feature enabled in MSRV checks where applicable * Add `esp32c6-lp-hal-procmacros` package to VS Code workspace * Update `CHANGELOG.md`
4 participants
1.67defmtfeature in the MSRV checkesp32c6-lp-hal-procmacrospackage to the VS Code workspaceThis unifies the various MSRV differences between RISC-V/Xtensa/async/defmt, so I think it's a nice improvement. Much simpler now, just a single version (as it should be).
Not sure why defmt was stated as requiring the latest
stablerelease previously, but it seems to build just fine in our MSRV check. If there is more to this, please provide some documentation so I can make a note of it for the future.@bjoernQ @MabezDev please let me know if you have any questions/concerns/objections to any of this. We should probably revisit our MSRV policy in the future, but I think for now this is a good balance.
Closes #788