-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix syntax error in the compiler #37278
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
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
0e93af8
to
9d179e6
Compare
It would be a good idea to audit all call sites of
This will be a subject for another PR. |
This change looks fine to me, but we should probably pass it through crater before we land it to just make sure that no one is accidentally relying on this being input without error. |
One more fun example: |
@nikomatsakis can we schedule a crater run here? Or should we try to fix all similar issues at once? |
Ok, let's just do everything in #37511 ? |
9d179e6
to
0b5f6d5
Compare
Ok, so #37511 turned out to be more complex that it seemed at first: it's not obvious that we want to forbid empty bounds everywhere. So let's just stick with fixing lifetimes in where clauses: it's already an error not to supply bounds for the type parameters, and it should be an error for lifetimes as well. The crater run in #37511 did not show any regression because of the lifetimes, so I think we can get away without a warning here. |
0b5f6d5
to
448da76
Compare
self.span_err(span, | ||
"each predicate in a `where` clause must have \ | ||
at least one bound in it"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we shouldn't make this an error until we reach a decision empty bounds lists in #37511.
@matklad could we just land the first two bullet points from #37511 (comment) in this PR? |
Don't allow lifetimes without any bounds at all
448da76
to
cf9ff2b
Compare
Yep, removing check for However, I can't add both I think it's ok to have a single test here, however I am very interested in parser recovery. Could you take a look at this question? |
Thanks! I agree that a single test is fine -- @bors r+ Regarding the question, rustc is capable of analyzing incomplete code, but the parser often isn't good enough at error recovery to get to analysis, even with |
📌 Commit cf9ff2b has been approved by |
Thanks a lot for the review, @jseyfried ! |
Fix syntax error in the compiler Currently `rustc` accepts the following code: `fn f<'a>() where 'a {}`. This should be a syntax error, shouldn't it? Not sure if my changes actually compile, waiting for the LLVM to build.
Currently
rustc
accepts the following code:fn f<'a>() where 'a {}
. This should be a syntax error, shouldn't it?Not sure if my changes actually compile, waiting for the LLVM to build.