Tracking issue for syn 2.0 inside rust-lang/rust

[Noratrieb]

syn 2.0 was just released!
https://github.com/dtolnay/syn/releases/tag/2.0.0

We should try to fully eliminate syn 1.0 from our dependency tree for better compile times.

The current ways in which we depend on syn 1:

Tasks

Beta Give feedback

1. synstructure (chalk and yoke) - Update to syn 2.0 mystor/synstructure#57
2. rustc_macros (requires synstructure support, migrate rustc_macros to syn 2.0 #109663)
3. chalk_derive (chalk) (requires synstructure) update syn to 2.0 chalk#793
4. askama_derive (used by rustdoc) bump askama_derive to 0.12.1 #109512
5. clap_derive (used by cargo and several other tools) bump treewide clap to 4.2.1 #110077
6. declare_clippy_lint bump syn to 2.0 rust-clippy#10621
7. derive_new (through rustfmt) - update to syn 2 nrc/derive-new#61
8. tracing-attributes (tracing, used in the compiler) attributes: update to syn 2.0 tokio-rs/tracing#2516
9. derive_more (used in rustc_middle) - Update to syn 2.0 JelteF/derive_more#249
10. displaydoc (used in icu4x) - Update syn requirement to 2.0 yaahc/displaydoc#42
11. futures_macro (dev dep of clippy) bump futures to use syn 2.0 #110079
12. icu_provider_macros: (icu4x)
13. proc-macro-error: (through clap)
14. serde_derive: (compiletest , cargo and probably more) Bump serde to use syn 2.0 #110078
15. thiserror-impl: (gitoxide through cargo) bump thiserror to use syn 2.0 #110081
16. zerovec-derive: (used in icu4x)
17. yoke-derive: (used in icu4x)
18. zerofrom-derive: (used in icu4x)
19. strum_macros (spdx, licensing)
20. unic-langid-macros-impl
21. derivative (unmaintained)

• and a few more

Fixing this involes updating the dependencies once they upgrade or contributing upgrades to them directly.

[jhpratt]

Mostly an aside: Is there a tracking issue for having a better (more thorough) proc macro API so that syn isn't necessary? I know there's #![feature(proc_macro_quote)] for output, but I'm not aware of anything for parsing.

[Manishearth]

The databake and zerovec derives are probably in this group. We should update ICU4X, and I can cut patch releases for those crates once we land the syn update upstream.

[w-flo]

Remaining syn1 reverse dependencies:

• color-print has an unreleased syn2 update in git
• darling 0.14 is an old version that still uses syn1, required by old version of derive_builder
• derivative seems a bit undermaintained currently, no commits in >2 years
• derive_builder decided not to update to syn2 as of now, as it would result in disruptive changes: Update syn dependency? colin-kiegel/rust-derive-builder#292 v0.20.0 is now available, which uses syn2 done
• derive_more has an unreleased syn2 update in git, and currently appears to be in a "try to get everything right" phase before the 1.0 release so it might take a bit longer
• html5ever has released 0.27 using syn2. ammonia has released 4.0.0 to depend on new html5ever. mdbook still needs to update to ammonia 4.0.0 in their git repo to eventually remove old html5ever from rust-lang/rust.
• strum 0.24 is an old version still using syn1, required by spdx-rs. spdx-rs has an unreleased update to strum 0.25 (which uses syn2) in git.
• thiserror-core-impl just needs a cargo update to the latest patch release
• unic-langid-macros-impl just needs a cargo update to the latest patch release

So other than derive_builder and derivative, it looks like it's just a matter of waiting for releases (and then possibly waiting for reverse dependencies to update to the new release if the update to syn2 happens to be released as a major release).

Edit: updated derive-builder is now available with syn2 dependency.

Edit: derive_more has released a syn2 backport for their current release, and color-print is now syn2, too. Only remaining syn1 deps in rust-lang/rust appear to be derivative (which still seems unmaintained and projects are starting to switch to educe or drop the derivative dependency in other ways) and strum_macros (which will be updated to syn2 when spdx-rs releases current git).

[GrigorenkoPV]

As you might have seen from the mentions, I have submitted a PR replacing derivative with a maintained alternative (#127042) and politely pestered the spdx-rs maintainers about making a new release (doubleopen-project/spdx-rs#33). When (and if) those two go through, the syn 1.* will officially be no more.