Do not emit type errors on recovered blocks #46732

estebank · 2017-12-14T19:49:51Z

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 · 2017-12-14T19:49:55Z

r? @petrochenkov

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

petrochenkov · 2017-12-14T21:35:28Z

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 · 2017-12-14T21:37:58Z

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 · 2017-12-14T21:49:30Z

@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:

pub struct Foo {
    text: String
}

pub fn parse() -> Foo {
    fn
    Foo { 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 · 2017-12-15T02:54:04Z

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

petrochenkov · 2017-12-15T09:32:02Z

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.

pub fn parse() -> Foo { <not_poisoned>
    let args: Vec<String> = env::args().collect();
    let text = args[1].clone();
    
    pub Foo { <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.

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

I need to make some experiments.

petrochenkov · 2017-12-16T11:54:34Z

src/libsyntax/parse/parser.rs

        }))
    }

    /// Parse a statement, including the trailing semicolon.
    pub fn parse_full_stmt(&mut self, macro_legacy_warnings: bool) -> PResult<'a, Option<Stmt>> {
-        let mut stmt = match self.parse_stmt_(macro_legacy_warnings) {
+        let mut stmt = match self.parse_stmt_without_recovery(macro_legacy_warnings)? {


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.

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

petrochenkov · 2017-12-16T11:55:23Z

src/test/ui/mismatched_types/recovered-block.rs

+
+    pub Foo { text }
+}
+//~^^ ERROR missing `struct` for struct definition


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

petrochenkov · 2017-12-16T11:59:54Z

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 · 2017-12-18T08:02:28Z

@bors r=petrochencov

bors · 2017-12-18T08:02:29Z

📌 Commit 351f06a has been approved by petrochencov

bors · 2017-12-18T08:02:39Z

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

Do not emit type errors on recovered blocks 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.

bors · 2017-12-18T09:24:58Z

💔 Test failed - status-appveyor

petrochenkov · 2017-12-18T20:52:57Z

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 · 2017-12-18T21:50:20Z

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

@bors r=petrochenkov

bors · 2017-12-18T21:50:22Z

📌 Commit 351f06a has been approved by petrochenkov

bors · 2017-12-19T09:43:20Z

⌛ Testing commit 351f06a with merge a6c1141a37b6b16e467ca070daf55948e9068045...

bors · 2017-12-19T10:50:12Z

💔 Test failed - status-travis

kennytm · 2017-12-19T17:35:24Z

RLS and rustfmt are still broken.

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.

estebank · 2017-12-21T23:10:23Z

@bors try

bors · 2017-12-21T23:10:33Z

⌛ Trying commit d90d5d1 with merge 91fe28d...

Do not emit type errors on recovered blocks 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.

bors · 2017-12-22T00:37:25Z

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

estebank · 2017-12-22T00:39:16Z

@bors r=petrochenkov

bors · 2017-12-22T00:39:16Z

📌 Commit d90d5d1 has been approved by petrochenkov

Do not emit type errors on recovered blocks 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.

bors · 2017-12-22T07:22:49Z

⌛ Testing commit d90d5d1 with merge c2ecab1...

bors · 2017-12-22T09:54:16Z

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

bluss · 2018-01-01T03:37:29Z

Awesome! Thanks a lot for this

rust-highfive assigned petrochenkov Dec 14, 2017

estebank mentioned this pull request Dec 14, 2017

suggest .. for erroneous ... in struct pattern; don't discard successfully-parsed fields on error #46721

Closed

estebank added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 14, 2017

estebank force-pushed the silence-recovered-blocks branch from ce52a2d to d2d3f94 Compare December 14, 2017 21:12

estebank force-pushed the silence-recovered-blocks branch 2 times, most recently from c6ceea9 to d99aef8 Compare December 14, 2017 23:40

estebank force-pushed the silence-recovered-blocks branch 2 times, most recently from 0d5a2f8 to 736e9b8 Compare December 15, 2017 07:55

estebank force-pushed the silence-recovered-blocks branch 4 times, most recently from d5c526f to 0d5b144 Compare December 16, 2017 01:16

petrochenkov reviewed Dec 16, 2017

View reviewed changes

kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 16, 2017

estebank force-pushed the silence-recovered-blocks branch 2 times, most recently from 9e392e2 to 351f06a Compare December 18, 2017 05:59

estebank added 2 commits December 21, 2017 14:57

Mark clippy as broken

d90d5d1

estebank force-pushed the silence-recovered-blocks branch from 351f06a to d90d5d1 Compare December 21, 2017 23:09

bors merged commit d90d5d1 into rust-lang:master Dec 22, 2017

bors mentioned this pull request Dec 22, 2017

[auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation #46554

Merged

topecongiro mentioned this pull request Dec 23, 2017

rustfmt-nightly not building on latest nightly rust-lang/rustfmt#2307

Closed

estebank mentioned this pull request Dec 23, 2017

Update RLS and Rustfmt and Cargo #46929

Closed

This was referenced Jan 15, 2018

Profoundly unhelpful compiler error message when "mod" accidentally used as "%" #45560

Closed

error causes subsequent spurious error about literal cast #35772

Closed

estebank mentioned this pull request Jan 28, 2018

Surpress, mark, or order superflous trait resolution type errors correctly #19406

Open

estebank mentioned this pull request Feb 12, 2018

parser should recover from seeing , when ; is expected #48160

Closed

This was referenced Feb 28, 2018

in which parentheses are suggested for should-have-been-tuple-patterns #48527

Merged

Emit fewer errors after parse errors #48724

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Do not emit type errors on recovered blocks #46732

Do not emit type errors on recovered blocks #46732

estebank commented Dec 14, 2017

rust-highfive commented Dec 14, 2017

petrochenkov commented Dec 14, 2017

petrochenkov commented Dec 14, 2017

estebank commented Dec 14, 2017

bors commented Dec 15, 2017

petrochenkov commented Dec 15, 2017

petrochenkov Dec 16, 2017

estebank Dec 17, 2017

petrochenkov Dec 16, 2017

estebank Dec 17, 2017

petrochenkov commented Dec 16, 2017

estebank commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 18, 2017

petrochenkov commented Dec 18, 2017

estebank commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 19, 2017

bors commented Dec 19, 2017

kennytm commented Dec 19, 2017

estebank commented Dec 21, 2017

bors commented Dec 21, 2017

bors commented Dec 22, 2017

estebank commented Dec 22, 2017

bors commented Dec 22, 2017

bors commented Dec 22, 2017

bors commented Dec 22, 2017

bluss commented Jan 1, 2018

Do not emit type errors on recovered blocks #46732

Do not emit type errors on recovered blocks #46732

Conversation

estebank commented Dec 14, 2017

rust-highfive commented Dec 14, 2017

petrochenkov commented Dec 14, 2017

petrochenkov commented Dec 14, 2017

estebank commented Dec 14, 2017

bors commented Dec 15, 2017

petrochenkov commented Dec 15, 2017

petrochenkov Dec 16, 2017

Choose a reason for hiding this comment

estebank Dec 17, 2017

Choose a reason for hiding this comment

petrochenkov Dec 16, 2017

Choose a reason for hiding this comment

estebank Dec 17, 2017

Choose a reason for hiding this comment

petrochenkov commented Dec 16, 2017

estebank commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 18, 2017

petrochenkov commented Dec 18, 2017

estebank commented Dec 18, 2017

bors commented Dec 18, 2017

bors commented Dec 19, 2017

bors commented Dec 19, 2017

kennytm commented Dec 19, 2017

estebank commented Dec 21, 2017

bors commented Dec 21, 2017

bors commented Dec 22, 2017

estebank commented Dec 22, 2017

bors commented Dec 22, 2017

bors commented Dec 22, 2017

bors commented Dec 22, 2017

bluss commented Jan 1, 2018