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!
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 docopt_macros
and quickcheck_macros
.
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.
https://github.com/rust-lang/rust/pull/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.
https://github.com/rust-lang/rust/pull/33041 will land in a few days. It changes the parser and some of the token tree representation
Note that https://github.com/rust-lang/rust/pull/31414 has been added to the rollup. It will break derive plugins, not sure what else.
Also https://github.com/rust-lang/rust/pull/33125
So far, we will be landing
once they all get approved
https://github.com/rust-lang/rust/pull/33157 is also in the list
Merging now: https://github.com/rust-lang/rust/pull/33179
It landed
For next batch (probably won't be any time soon):
I don't think @erickt works on Serde very actively at this point, since he has lots of other duties. Is there another maintainer that should be CCed on this issue?
I was going to start doing serde ups but I haven't had the time and I might not get it for a month.
@petrochenkov Probably should make your PRs nowish given that the ..
one will need to land soon.
Batch should happen in a day or two: https://github.com/rust-lang/rust/pull/33864
cc @erickt @dtolnay @sgrif
Batch landed!
@Manishearth
I was going to start doing serde ups but I haven't had the time and I might not get it for a month.
What's involved? I'm interested in keeping syntex_syntax
close to libsyntax
so that rustfmt keeps up.
Um, ask @erickt
@kamalmarhubi https://github.com/serde-rs/syntex/blob/master/CONTRIBUTING.md#how-to-do-a-syntex_syntax-release
and then you fix up aster and quasi to do the same
@Manishearth I was about to come here and link that to answer myself, but you're quick! :-)
PRs for next batch:
mergerollup josephDunne:trait_item_macros 34213 nrc
mergerollup jseyfried:refactor_ast_stmt 34316 eddyb
mergerollup jseyfried:thin_vec 34339 petrochenkov,Manishearth
mergerollup petrochenkov:astqpath 34368 Manishearth
mergerollup cgswords:tstream 34385 nrc
mergerollup jonathandturner:move_liberror 34403 alexcrichton
In case it affects anyone else - #34272 was a breaking change for Aster. https://github.com/serde-rs/aster/issues/88. I guess nobody noticed because rustup has been serving up nightly 2016-06-15 until recently.
This would be a good time to merge the other 5 if they are ready.
Cc me.
(sorry for the noise but for some reason GitHub never notifies me for this despite I've subscribe to the thread)
@dtolnay sorry about that, I underestimated how much of the libsyntax
API was being used by third parties. I'll be sure to check aster/serde in the future before landing anything borderline.
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).
cc @dtolnay @BurntSushi @sgrif @sfackler @llogiq
Landed!
Stuff for next batch:
- https://github.com/rust-lang/rust/pull/36551
mergerollup CensoredUsername:stmt_let_typed_fix 35874 Manishearth
mergerollup jonas-schievink:whats-a-pirates-favorite-data-structure 36599 pnkfelix
mergerollup pnkfelix:attrs-on-generic-formals 34764 eddyb
@Manishearth don't know if it's to late for the two other PRs to make it into the next nightly, but https://github.com/rust-lang/rust/pull/36551 was a syntax breaking change and has already been merged.
Too late :/ But we're rolling it up now anyway
Breaking batch at https://github.com/rust-lang/rust/pull/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.
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.
Most helpful comment
Everything seems reviewed, breaking batch will be made todayish (and land over the weekend).
cc @dtolnay @BurntSushi @sgrif @sfackler @llogiq