Detect possibly non-Rust closure syntax during parse

[estebank]

Other languages have a similar, but not quite the same to Rust, syntax
for closures:

{|<args>| <stmts> }

Even worse, the above code is valid Rust if and only if there's only
one statement, as the block would resolve to the single statement
closure within it. This means that seemingly correct code will fail when
adding a new statement, making modifying something that looks unrelated
cause "value not found in this scope" and "trait bound not satisfied"
errors. Because of this, make the parser detect the specific case where
the code is incorrect and failing, and emit a warning explaining the
correct syntax.

Fix #27300.

[rust-highfive]

r? @michaelwoerister

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

[varkor]

Typo: "implicitly".

[petrochenkov]

This is a semantic error, so I'd rather not report it in the parser.
Hard-coded warnings should be avoided as well if possible.

Given that, I think there are two possibilities:

• Attach the message to type errors and resolution errors if they originate from the suspicious closure-like block. That's kinda hard and doesn't worth the effort, IMO.
• Make it an early warn-by-default lint, then the explanatory message will be shown even if there are resolution errors.

[petrochenkov]

This is also somewhat a policy question, like @Xirdus mentioned in #27300 (comment).
There are large number of popular enough languages with variety of syntaxes, we should not necessarily try to parse them all and report custom messages, especially if it requires going out of our way somehow.
People with Ruby background is a common source of Rust newcomers... for reasons, so I think it would be probably okay if this special diagnostics are implemented, especially as a self-contained lint.

[shepmaster]

@petrochenkov I'm unclear on why you marked this as waiting on author — what kind of response are you expecting from @estebank? If this needs a "policy decision", then it seems like it needs to go to the appropriate team, instead.

[petrochenkov]

@shepmaster

what kind of response are you expecting from @estebank?

Making this an early warn-by-default lint instead of a hardcoded warning in parser.

If this needs a "policy decision"

I'm not entirely sure this needs a larger policy decision than rubber-stamping from me, but let's tag it as compiler-team-nominated anyway.

[nikomatsakis]

I'm going to clear the nominated flag. My feeling is that targeted errors of this kind are worth it, if they are not too intrusive -- it's hard to make a hard-and-fast rule, but I love the reputation of rustc as a "helpful compiler", and if we see a place that people stub their toes a lot, we should try to patch that. (In particular, I see no reason to pretend other languages don't exist.)

All that said, I don't have a strong opinion about whether this particular message should be given in the parser or a lint or what. I'd say that if the code does successfully parse, then some sort of lint seems like a better place for it.

[pietroalbini]

@estebank the reviewer asked to turn this into an early warn-by-default lint in #47763 (comment), could you do that?

[estebank]

@pietroalbini I'll get back to this sometime this week to turn it into a lint.

[shepmaster]

Would you also submit the opposite patch to Ruby 😇? Surprisingly, that's the biggest stumbling block I have switching between the two...

[pietroalbini]

@estebank this PR has been stale for more than two weeks, so I'm closing it. If you have time to work on this again in the future feel free to reopen it!