Uh oh!
There was an error while loading. Please reload this page.
Prevent where < ident > from parsing. - #38268
Conversation
In order to be forward compatible with `where<'a>` syntax for higher rank parameters, prevent potential conflicts with UFCS from parsing correctly for the near term.
rust-highfive
commented
Dec 9, 2016
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
withoutboats
commented
Dec 9, 2016
This is my first PR to rustc! 🎉 I think this is correct, though I don't have any idea at all what error message to issue in this case. See also rust-lang/rfcs#1598 for background on this change. cc @rust-lang/lang r? @eddyb |
| *t == token::Gt || *t == token::Comma || *t == token::Colon | ||
| }); | ||
| if gt_comma_or_colon { | ||
| return Err(self.fatal("TODO How to even explain this error?")); |
There was a problem hiding this comment.
This is a recoverable error, no need to return Err.self.err("syntax `where<T>` is reserved for future use"); would be more appropriate.
There was a problem hiding this comment.
Should we consume tokens until the the next Gt in that case?
There was a problem hiding this comment.
Nah, if it's indeed <A>::B: Tr (more likely), then it'll parse successfully without consuming extra tokens, otherwise (less likely) it doesn't matter.
There was a problem hiding this comment.
But don't we want it to parse as ::B: Tr1? I suppose it doesn't matter much since it errors anyway.
LGTM, I'll start a crater run. |
eddyb
commented
Dec 10, 2016
@brson Looks like crater is busted again, build completes successfully but then: |
withoutboats
commented
Dec 15, 2016
Any update on crater? This wants to land before the next beta is cut. |
eddyb
commented
Dec 16, 2016
@withoutboats If you rebase I could try again, but I didn't hear back from @brson on this. |
withoutboats
commented
Dec 16, 2016
Cool, I'll rebase when I get home tonight |
brson
commented
Dec 16, 2016
@eddyb This is because of the change to rustbuild. Also changes to cargo's release process broke crater. So crater can neither build custom rustc nor install the latest cargo nightlies atm. I can't get to it this week I'm afraid, but next. |
brson
commented
Dec 22, 2016
I'll crater. |
withoutboats
commented
Dec 22, 2016
oops i forgot to rebase this, let me know if thats a problem |
brson
commented
Dec 23, 2016
Crater says: https://gist.github.com/anonymous/4ad4a0abf91b713fa58d7771ad281de0 Looks like no regressions, 1 false positive. |
withoutboats
commented
Dec 23, 2016
Awesome, what are the steps to landing & backporting this to 1.15 beta? |
aturon
commented
Dec 23, 2016
bors
commented
Dec 23, 2016
📌 Commit 14e4b00 has been approved by |
bors
commented
Dec 24, 2016
…ddyb Prevent where < ident > from parsing. In order to be forward compatible with `where<'a>` syntax for higher rank parameters, prevent potential conflicts with UFCS from parsing correctly for the near term.
bors
commented
Dec 24, 2016
nikomatsakis
commented
Dec 30, 2016
Why do we want this on 1.15 beta? |
eddyb
commented
Dec 30, 2016
Because in 1.15, one of my PRs made it so |
nikomatsakis
commented
Dec 30, 2016
OK, marking as beta-accepted. cc @rust-lang/compiler |
syntax: Rewrite parsing of impls Properly parse impls for the never type `!` Recover from missing `for` in `impl Trait for Type` Prohibit inherent default impls and default impls of auto traits (#37653 (comment), #37653 (comment)) Change wording in more diagnostics to use "auto traits" Fix some spans in diagnostics Some other minor code cleanups in the parser Disambiguate generics and qualified paths in impls (parse `impl <Type as Trait>::AssocTy { ... }`) Replace the future-compatibility hack from #38268 with actually parsing generic parameters Add a test for #46438
In order to be forward compatible with
where<'a>syntax for higherrank parameters, prevent potential conflicts with UFCS from parsing
correctly for the near term.