Uh oh!
There was an error while loading. Please reload this page.
syntax/hir: give loop labels a span - #33351
Conversation
rust-highfive
commented
May 2, 2016
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
jonas-schievink
commented
May 2, 2016
This is a libsyntax [breaking-change], right? In that case, cc #31645 and cc @Manishearth, not sure how big the impact would be. |
birkenfeld
commented
May 2, 2016
I suppose so, yes. There might also be a reason for these not to have a span, I don't know :) |
Manishearth
commented
May 2, 2016
Nah, lots of things don't have a span just because it's not necessary. But yeah, to whoever reviews this: please just write r=whatever without mentioning bors, don't actually approve it. This will be merged when we have sufficient other libsyntax breaking changes. |
llogiq
commented
May 2, 2016
So I could help getting this merged by breaking libsyntax in other ways? 😜 |
Manishearth
commented
May 2, 2016
lol. Make a change large enough that it's going to need rebases every day and I'm fine with batching up now, otherwise we really should wait. |
birkenfeld
commented
May 4, 2016
@Manishearth isn't Niko's diagnostics change pretty breaking? At least it will break clippy (cf PR there). |
Manishearth
commented
May 4, 2016
[breaking-batch] applies to libsyntax public APIs and semantics only, since that breaks syntax extensions and the serde/aster/quasi stuff -- this leads to a disturbance in the Force, as if millions of lockfiles suddenly cried out in terror. On the other hand, clippy doesn't break dependencies since people don't use it as a mandatory dependency (or shouldn't, at any rate), so it's just a matter of ignoring clippy failures in travis for a day. Problematic, but less so. Besides, clippy depends on so many random-and-totally-unstable bits of the compiler that we'd be freezing too much. OTOH it's pretty okay if libsyntax's API is somewhat frozen, since it's mostly not going to change anyway. |
bors
commented
May 10, 2016
☔ The latest upstream changes (presumably #33443) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
(I'd personally prefer if let Some(sp_ident) to for here, but I won't block this PR on that nit.)
There was a problem hiding this comment.
That's how I'd write it too, I kept it consistent with existing code (line 826).
pnkfelix
commented
May 10, 2016
@Manishearth r=me |
bors
commented
May 14, 2016
☔ The latest upstream changes (presumably #33532) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
commented
May 18, 2016
☔ The latest upstream changes (presumably #33654) made this pull request unmergeable. Please resolve the merge conflicts. |
birkenfeld
commented
May 18, 2016
@Manishearth please let me know when a batch is about to land. I don't want to rebase for no reason. |
Manishearth
commented
May 24, 2016
Could you rebase this? The batch will happen soon |
This makes the "shadowing labels" warning *not* print the entire loop as a span, but only the lifetime. Also makes rust-lang#31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
…elix This makes the \"shadowing labels\" warning *not* print the entire loop as a span, but only the lifetime. Also makes rust-lang#31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
…elix This makes the \"shadowing labels\" warning *not* print the entire loop as a span, but only the lifetime. Also makes rust-lang#31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).
This makes the "shadowing labels" warning not print the entire loop as a span, but only the lifetime.
Also makes #31719 go away, but does not fix its root cause (the span of the expanded loop is still wonky, but not used anymore).