Closed Enet4 closed 1 year ago
Yeah, I've been eyeing that. The "problem" is that it also comes with a MSRV bump, which means SNAFU will have to have a MSRV bump and thus bump the minor version. Bumping the MSRV should also involve checking and cleaning things like the rust_1_39
and rust_1_46
features. It would also allow us to finally move to edition 2021.
Rust 1.56 was 2021-10-21, so hopefully people will have been able to upgrade by now.
Have you tried bumping the syn version / any ideas what kind of changes are needed?
As a point of reference, Debian has Rust 1.63 in its stable release, 1.48 in "oldstable", and 1.41 in "oldoldstable" (long-term support out to 2024-06-30). Alpine Linux 3.15 and newer have Rust 1.56 and newer; Alpine 3.10, the oldest not-completely-unsupported version covered by the package catalog, has Rust 1.34. I'm not sure any other distro both packages Rust and is conservative in updating it similarly to Debian; Debian at least is the most famous. Fedora, Ubuntu, Arch, Gentoo, NixOS, and Guix seem to have Rust 1.56 or newer available for all supported releases of the distro (if it's not rolling-release), and I'm not sure OpenSUSE packages Rust at all except in a rolling-release version, in which Rust appears to be updated frequently.
Have you tried bumping the syn version / any ideas what kind of changes are needed?
Just gave it a try. The trickiest part was adjusting the DocComment
definition to comply with the way that attributes are parsed in the new version (it's hard for me to explain why), the rest was renaming a type and changing a field access to a method call.
A good deal of the code changes would still be around requiring Rust 1.56, mostly to clean up conditional attributes and removing outdated content. I pushed them all into this branch which I hope do both of these well. Let me know if you would be willing to consider a PR with this.
Sure, feel free to open that as a PR where we can iterate and comment.
I'd like to say that I, supporting generous MSRVs, appreciate SNAFU's current generosity in its MSRV, but I, getting it for free, don't ask that that generosity be in any way permanent, particularly if it's incurring the cost in time-to-compile of an otherwise unnecessary and not small dependency.
A major version of syn (v2.0) was released a while ago. In my projects, all other syn dependents but snafu have done the jump. Would you be interested in a PR to migrate syn to version 2?