parser: recover on for<'a> |...| body closures

[Centril]

When encountering for and < is 1 token ahead, interpret this as an explicitly quantified generic closure and recover, rather than attempting to parse a for loop. This provides both improved diagnostics as well as an insurance policy for the ability to use this as the syntax for generic closures in the future.

As requested by r? @eddyb

[eddyb]

I guess what I was worried about is this any early exist from here resulting in a for loop successfully parsing but I guess that's not possible.

[eddyb]

I wonder if the language here could be more focused on the present rather than sounding absolute. Like "not yet supported" but maybe not suggesting future support is certain?

[Centril]

We tend to shy away from "not yet" so as to not suggest that it will happen; "cannot" is a fairly standard start of a diagnostic message in the compiler.

[eddyb]

cc @petrochenkov@nikomatsakis I don't want to unilaterally approve this, but I've been wanting make sure we don't paint ourselves into a corner wrt generic closure syntax (i.e. by it being ambiguous with for <...>::... in ... {...} loops), and it looks like irrefutable patterns starting with < have become possible more recently.

[petrochenkov]

I'm mildly skeptical about this, the syntax is unlikely to be written accidentally, so there's not much motivation for doing this for recovery.

Regarding future proofing, we already have ambiguities "< as a start of generics" vs "< as a start of qpath", and they are treated with choose_generics_over_qpath, so if this PR is primarily about future-proofing, it should use that function as well.

[Centril]

Switched over to choose_generics_over_qpath as this is indeed primarily about future proofing for generic closures (though the recovery diagnostics don't hurt imo).

As for the for-loop thing. Keeping in mind that these must be irrefutable patterns using <...>::Variant as a syntax in for loops specifically, that they must be enums (univariant ones), and that they have only worked semantically since 1.37, it's exceedingly unlikely that anything relies on this.

r? @petrochenkov

[petrochenkov]

@bors r+

[bors]

📌 Commit 4d30b92 has been approved by petrochenkov

[qnighy]

Is it ok that this artificial example no longer compiles in nightly? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c444d791d838b73c5ad3e9813e9838c6

#[derive(PartialEq,Eq)]structA;implA{constA:A = A;}fnmain(){for <A>::Ainvec![A]{}}

[nikomatsakis]

So, let me understand what happened here:

• We've modified the parser so that for< is now considered the start of a closure and not a for loop -- this is a change to the previous behavior for sure, right? Not saying I disagree with it, but it seems like it'd have been good to at least ping @rust-lang/lang and provide some motivation
• Based on what I see elsewhere in the PR, my assumption is that the motivation is to eventually permit for<'a> |&'a u32| -> &'a u32 in closure type signature annotations?
• Did we do any kind of crater run or check to see if this would be widely used? It seems like at minimum this probably merits a relnotes tag?
• In any case, I'm nominating for lang team discussion.

[fmease]

for future reference, linking rust-lang/rfcs#3216

[dtolnay]

As for the for-loop thing. Keeping in mind that these must be irrefutable patterns using <...>::Variant as a syntax in for loops specifically, that they must be enums (univariant ones), and that they have only worked semantically since 1.37, it's exceedingly unlikely that anything relies on this.

This is referring to #61682. An irrefutable pattern with a uni-valued associated constant would have worked since Rust 1.20 (#42809) — but is even less likely to appear in real code.

structT;implT{constUNIT:() = ();}fnmain(){let _ = for <T>::UNITinNone{};}