refactor(macros): bump syn to v3 - #679
Conversation
| }; | ||
|
|
||
| if f.sig.unsafety.is_none() { | ||
| if !matches!(f.sig.safety, syn::Safety::Unsafe(_)) { |
There was a problem hiding this comment.
Function "safety" is now encoded with a 3-variant enum.
| }; | ||
|
|
||
| if f.sig.unsafety.is_none() { | ||
| if !matches!(f.sig.safety, syn::Safety::Unsafe(_)) { |
There was a problem hiding this comment.
Function "safety" is now encoded with a 3-variant enum.
| proc-macro2 = "1.0.106" | ||
| quote = "1.0.45" | ||
| syn = { version = "2.0.117", features = ["extra-traits", "full"] } | ||
| syn = { version = ">= 2.0.117, < 4", features = ["extra-traits", "full"] } |
There was a problem hiding this comment.
cortex-m-macros seems to work with either syn v2 or v3: this allows both but, because cortex-m-rt-macros does depend on the v3 specifically, and as most dependents use both, you may prefer to depend on the v3 to simplify this a bit:
| syn = { version = ">= 2.0.117, < 4", features = ["extra-traits", "full"] } | |
| syn = { version = "3.0", features = ["extra-traits", "full"] } |
Allowing both versions allows dependents that only depend on cortex-m-macros and don't otherwise have a (transitive) dependency on syn v3 to only use syn v2, thus avoiding the dependency duplication.
There was a problem hiding this comment.
I think a big pro of the simpler 3.0 dep is that it's far less likely to break something by accident. If someone accidentally uses a 3.0 feature without updating the syn dep, you're breaking everyone with syn 2 in their lock files.
Not worth it IMO
There was a problem hiding this comment.
Makes sense! I've simplified to just list syn v3.
diondokter
left a comment
There was a problem hiding this comment.
Looks good to me, though see my thoughts on the syn version
3ed9ea5 to
1b71455
Compare
Following the release of a new major version of
syn, this bumps the version used bycortex-m-macrosandcortex-m-rt-macros, with the goal of eventually removing the duplicated dependency in binaries (and therefore reducing compile times).synv3 advertises an MSRV of 1.71, so this shouldn't affect the MSRV of these crates given the recent bump to 1.85.I've gone through the changelog and did the necessary refactor; I didn't find any other relevant breaking changes (but there are quite a few of them so I could have missed some). I've run
cargo testbut didn't do any other kind of testing.