Do not emit type errors on recovered blocks

[estebank]

When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as ()) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.

Fix#44579.

[rust-highfive]

r? @petrochenkov

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

[petrochenkov]

The case reported in #44579 is 100% reasonable recovery.
The "mismatched types" error is exactly what would be reported if the pub struct Pub items wasn't ill-formed, so I'd close this as not-a-defect.

(Also, the "unmatched visibility" wording was really weird and unhelpful (unmatched with what?), it's really nice that it's changed to "missing struct" on nightly.)

[petrochenkov]

Output on nightly, the first error is much more visible now:

error: missing `struct` for struct definition
--> src/main.rs:11:8
|
11 | pub Foo { text } // NB: Syntax error here
| ^
help: add `struct` here to parse `Foo` as a public struct
|
11 | pub struct Foo { text } // NB: Syntax error here
| ^^^^^^
error[E0308]: mismatched types
--> src/main.rs:7:23
|
7 | pub fn parse() -> Foo {
| _______________________^
8 | | let args: Vec<String> = env::args().collect();
9 | | let text = args[1].clone();
10 | | 11 | | pub Foo { text } // NB: Syntax error here
12 | | }
| |_^ expected struct `Foo`, found ()
|
= note: expected type `Foo`
found type `()`

[estebank]

@petrochenkov the first error is more prominent now in this case, but any syntax error will cause the type error to happen. Consider the following case instead:

pubstructFoo{text:String}pubfnparse() -> Foo{fnFoo{ text:"".to_string()}}

error: expected one of `(` or `<`, found `{`
--> src/main.rs:7:9
|
7 | Foo { text: "".to_string() }
| ^ expected one of `(` or `<` here
error[E0308]: mismatched types
--> src/main.rs:5:23
|
5 | pub fn parse() -> Foo {
| _______________________^
6 | | fn
7 | | Foo { text: "".to_string() }
8 | | }
| |_^ expected struct `Foo`, found ()
|
= note: expected type `Foo`
found type `()`
error: aborting due to 2 previous errors

The second error won't happen once the syntax error is fixed, but the compiler can't know that, and it is still the most vertically prominent error in the output. I feel that masking the type error when we know the block had a parse error (that we made an effort to continue after) is a better default.

[bors]

☔ The latest upstream changes (presumably #46641) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

If some piece of code look so similar to a legal statement that we recover it as a legal statement (e.g. an item statement in case of pub struct Foo), then it should not poison the outer block in which it's defined, only possibly its inner block.

pubfnparse() -> Foo{ <not_poisoned>
let args:Vec<String> = env::args().collect();let text = args[1].clone();pubFoo{ <poisoned> text </poisoned> }
</not_poisoned> }

In the example with fn it looks like we don't recover fn Foo { text: "".to_string() } as a function item statement, it's interpreted as just some random token soup. In this case it should indeed poison the block in which it's defined.

pubfnparse() -> Foo{ <poisoned>
fn
Foo{text:"".to_string()}
</poisoned> }

I need to make some experiments.

[petrochenkov]

This seems to be a change independent from adding the recovered flag to blocks?
From what I see in the test diffs I'd keep this recovery in place.

[estebank]

The recovery happens in the callee already, and using parse_stmt_ swallows errors that we do want to see in parse_block_tail.

[petrochenkov]

Could you add the example with fn (#46732 (comment)) as a test too?

[estebank]

added

[petrochenkov]

r=me with comments addressed

I still want to look at the statement recovery more carefully, but not right now (probably replace the recovered flag with ExprKind::Err and statements based on it). Into backlog it goes...

[estebank]

@bors r=petrochencov

[bors]

📌 Commit 351f06a has been approved by petrochencov

[bors]

⌛ Testing commit 351f06a with merge 184693d...

[bors]

💔 Test failed - status-appveyor

[petrochenkov]

How do we deal with cross-repo commits?

rustfmt and rls are marked as "Broken" in https://github.com/rust-lang/rust/blob/master/src/tools/toolstate.toml, a pull request to rustfmt can be sent asyncroniously.

[estebank]

Already marked as broken, looks like the failure was due to sscache.

@bors r=petrochenkov

[bors]

📌 Commit 351f06a has been approved by petrochenkov

[bors]

⌛ Testing commit 351f06a with merge a6c1141a37b6b16e467ca070daf55948e9068045...

[bors]

💔 Test failed - status-travis

[kennytm]

RLS and rustfmt are still broken.

[estebank]

@bors try

[bors]

⌛ Trying commit d90d5d1 with merge 91fe28d...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[estebank]

@bors r=petrochenkov

[bors]

📌 Commit d90d5d1 has been approved by petrochenkov

[bors]

⌛ Testing commit d90d5d1 with merge c2ecab1...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing c2ecab1 to master...

[bluss]

Awesome! Thanks a lot for this