Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix breakage stemming from Syn MSRV bump #1085

Open
jswrenn opened this issue Apr 2, 2024 · 2 comments
Open

Fix breakage stemming from Syn MSRV bump #1085

jswrenn opened this issue Apr 2, 2024 · 2 comments

Comments

@jswrenn
Copy link
Collaborator

jswrenn commented Apr 2, 2024

Starting with #1081, our nightly toolchain roller began to fail. The cause was syn increasing its MSRV to 1.60 from 1.56. Our MSRV remains at 1.56, so CI builds on that toolchain began to fail to resolve a suitable version of syn.

The timeline of events on syn's side is a little confusing:

  1. March 21: Raise required compiler to rust 1.60
  2. March 23: Release 2.0.54
  3. March 23: Restore compatibility with rustc 1.56 through 1.59
  4. March 23: Release 2.0.55
  5. March 29: chore: bump msrv to 1.60 in Use dep: and optional dependency feature ? syntax dtolnay/syn#1608
  6. March 29: Release 2.0.56

Not yet sure how we should proceed with this. A few possibilities that spring to mind:

  • We build in CI with -Z minimal-versions
  • We downgrade to syn 1.x (MSRV is 1.31)
  • We vendor (or reimplement) the parts of syn relevant to zerocopy-derive
  • We delete our MSRV policy on zerocopy-derive; we cannot guarantee an MSRV for that crate, since it has dependencies with different MSRV policies.
  • Ask syn to adopt a more conservative MSRV policy.
@weihanglo
Copy link

Could also consider committing a MSRV compatible Cargo.lock, so it becomes a source of true of what is buildable. And Optionally have a non-blocking "latest version" job for verification purpose.

See also Verifying rust-version and Verifying Latest Dependencies for some CI pracitices.

joshlf added a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
@joshlf
Copy link
Member

joshlf commented Apr 2, 2024

I've put up a PR to temporarily pin syn to a known-good version so that we can unblock CI: #1089. That's obviously not a complete fix, so I've filed #1088 and blocked releasing 0.8 (#671) on it.

joshlf added a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
github-merge-queue bot pushed a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants