-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for libsyntax breaking changes #31645
Comments
I would also like to re-submit my plea that commits with breaking changes are tagged, and if possible, at least some message that hints at or explains how to fix breakages. Other crates with macros in use (apparently) are |
Yeah, they get tagged with [breaking-change]. With this bug in place they should also be posted here first and we can notify everyone well in advance before a rollup. |
[breaking-batch] Add support for `pub(restricted)` syntax in the AST This PR allows the AST to represent the `pub(restricted)` syntax from RFC 1422 (cc #32409). More specifically, it makes `ast::Visibility` non-`Copy` and adds two new variants, `Visibility::Crate` for `pub(crate)` and `Visitibility::Restricted { path: P<Path>, id: NodeId }` for `pub(path)`. plugin-[breaking-change] cc #31645 r? @pnkfelix
#32767 is a breaking change that will land soon, along with #32688. I'd normally wait a few days before merging these so that everyone can fix their code early, but in this case #32688 already landed so there's not much I can do. This will definitely break syntex and friends, cc @erickt. I've never looked at diesel's code so it may or may not break it, @sgrif you may want to have a look before this lands in the nightly. |
Thanks for the ping, definitely going to cause breakage. |
The AST part of rust-lang#31937 Unlike HIR, AST still uses `Option` for field names because parser can't know field indexes reliably due to constructions like ``` struct S(#[cfg(false)] u8, u8); // The index of the second field changes from 1 during parsing to 0 after expansion. ``` and I wouldn't like to put the burden of renaming fields on expansion passes and syntax extensions. plugin-[breaking-change] cc rust-lang#31645 r? @Manishearth
#33041 will land in a few days. It changes the parser and some of the token tree representation
|
Note that #31414 has been added to the rollup. It will break derive plugins, not sure what else. |
Also #33125 So far, we will be landing
once they all get approved |
#33157 is also in the list |
…arth Track the span corresponding to the `|...|` part of the closure. lifted from rust-lang#32756 cc rust-lang#31645 libsyntax-[breaking change]
Merging now: #33179 |
Next breaking batch will contain the above PRs, waiting on the last one. cc @dtolnay @sfackler @mystor @sgrif @BurntSushi |
Everything seems reviewed, breaking batch will be made todayish (and land over the weekend). |
Batch at #36066 |
Landed! |
Stuff for next batch:
|
@Manishearth don't know if it's to late for the two other PRs to make it into the next nightly, but #36551 was a syntax breaking change and has already been merged. |
Too late :/ But we're rolling it up now anyway |
…orite-data-structure, r= Contains a syntax-[breaking-change] as a separate commit (cc rust-lang#31645).nnAlso renames slice patterns from `PatKind::Vec` to `PatKind::Slice`.
Breaking batch at #36857 cc @dtolnay @sgrif @BurntSushi Will merge tomorrowish. |
This is exciting - I am not planning to do a serde_macros release so we will see if people revolt or move to serde_derive. |
Should we PSA this? |
The announcement that we are dropping serde_macros was at the top of reddit for a while and also popular on u.r-l.o. I think people will put two and two together when their builds fail. Worst case we get a handful of issues filed and we point them to the announcement. Do you know a better way to reach people who have not seen either of those already? |
You could potentially cut a new release that panics with a message telling people to move to serde-derive. |
@dtolnay Has this been announced in the Project Updates section of TWiR? |
No we just missed the last one. |
The panicky method feels a bit invasive imo. It should be worth mentioning somewhere (perhaps on the crates.io page, or in the readme) that the method for upgrading is to switch over to the new macro version. |
If it has access to the diagnostics machinery, printing a deprecation warning wouldn't be that hard. |
…orite-data-structure, r=pnkfelix Contains a syntax-[breaking-change] as a separate commit (cc rust-lang#31645).nnAlso renames slice patterns from `PatKind::Vec` to `PatKind::Slice`.
This landed. beware the breakage! |
We should be done with the macros 1.1 port later today so I no longer need to get pinged on these. Thank you for including me though! |
Proc macros are not tied to libsyntax now, so this is no longer relevant. |
See also: https://internals.rust-lang.org/t/please-consider-stability-of-libsyntax/2947
We decided to batch up breaking changes to oft-used unstable compiler internals (mainly, libsyntax) until they're large enough; so that the impact of these breaking changes is minimized. (For example, every time libsyntax breaks, aster and transitively everyone using serde on nightly has to fix it)
Let's try to coordinate these in the future through this issue. We can list breaking PRs here and batch them up when we feel that they're large enough (or when there's another inevitable breaking change about to merge). Merge them when there's enough time for the folks below to know about it, and preferably make PRs to the larger projects below beforehand.
CCing stakeholders:
Add more if you know of them!
The text was updated successfully, but these errors were encountered: