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:

- [ ] `synstructure` (chalk and yoke) - https://github.com/mystor/synstructure/pull/57
- [x] `rustc_macros` (requires `synstructure` support, #109663)
- [x] [`chalk_derive`](https://github.com/rust-lang/chalk/blob/master/chalk-derive/Cargo.toml) (chalk) (requires `synstructure`) https://github.com/rust-lang/chalk/pull/793
- [x] `askama_derive` (used by rustdoc) #109512
- [x] `clap_derive` (used by cargo and several other tools) #110077
- [x] `declare_clippy_lint` https://github.com/rust-lang/rust-clippy/pull/10621
- [ ] `derive_new` (through rustfmt) - https://github.com/nrc/derive-new/pull/61
- [x] `tracing-attributes` (tracing, used in the compiler) https://github.com/tokio-rs/tracing/pull/2516
- [ ] `derive_more` (used in rustc_middle) - https://github.com/JelteF/derive_more/issues/249
- [x] `displaydoc` (used in icu4x) - https://github.com/yaahc/displaydoc/pull/42
- [x] `futures_macro` (dev dep of clippy) #110079
- [ ] `icu_provider_macros`: (icu4x)
- [x] `proc-macro-error`: (through clap)
- [x] `serde_derive`: (compiletest , cargo and probably more) #110078
- [x] `thiserror-impl`: (gitoxide through cargo) #110081
- [ ] `zerovec-derive`: (used in icu4x)
- [ ] `yoke-derive`: (used in icu4x)
- [ ] `zerofrom-derive`: (used in icu4x)
- [ ] `strum_macros` (spdx, licensing)
- [ ] `unic-langid-macros-impl`
- [ ] `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: https://github.com/colin-kiegel/rust-derive-builder/issues/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.