Fix syntax error in the compiler

[matklad]

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.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[matklad]

It would be a good idea to audit all call sites of parse_ty_param_bounds and make sure (refactor) that empty bounds are not allowed. There is at least one more place where the check is missing:

trait T {}
type S = for<'a> T+; // <- plus what? fn main() {}

This will be a subject for another PR.

[pnkfelix]

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.

[matklad]

One more fun example: fn foo<T:>(x: T) -> T { x }

[matklad]

@nikomatsakis can we schedule a crater run here? Or should we try to fix all similar issues at once?

[matklad]

Ok, let's just do everything in #37511 ?

[matklad]

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.

[jseyfried]

I think we shouldn't make this an error until we reach a decision empty bounds lists in #37511.

[jseyfried]

@matklad could we just land the first two bullet points from #37511 (comment) in this PR?
That might just be the eat -> expect change along with the fallout and test cases.

[matklad]

Yep, removing check for bound.is_empty() for now seems prudent!

However, I can't add both where 'a and where 'a 'b tests to a single file even though there is -continue-parse-after-error. Looks like the parser can't recover in this case and skip tokens until the start of the next item.

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?

[jseyfried]

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 continue-parse-after-error. I'm not sure exactly why we don't recover in this case, but I could help look into it if you'd like to work on improving error recovery (feel free to ping me on IRC).

[bors]

📌 Commit cf9ff2b has been approved by jseyfried

[matklad]

Thanks a lot for the review, @jseyfried !

[bors]

⌛ Testing commit cf9ff2b with merge 8289a89...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: jseyfried
Pushing 8289a89 to master...