parse errors result in massive, useless spew #31994
Comments
|
I blame the fact that we’re trying to recover from errors too hard. At the very least we should not continue into resolve after parse failures, should we? That will never work out. |
|
I think continuing after parse errors can work well, but perhaps we should disable this sort of recovery on stable channels until we are better able to handle it. Another common failure I see is lifetime errors due to random type-checking failures -- I'm not exactly sure what causes those, but I'm sure you all have seen them. |
|
We could recover "opt in" with |
|
Although not related to parse errors, I've found a very similar bug related to worse error messages in the case of a resolve failure: #31997 |
|
We probably want some kind of meta issue here, ultimately -- but my feeling is that we should continue to work towards better support for generating more errors, but we should not jump the gun and inflict these things on the "waiting public" until they are ready. cc @rust-lang/compiler @rust-lang/tools |
|
I personally like the idea of perhaps a |
The main reason I proposed having the more advanced errors enabled by default (not behind a flag) on nightly was to ensure that we actually exercise the code, find ICEs, and so forth... |
|
We discussed in the @rust-lang/core meeting today. General feeling was that we should make surgical changes to try and stop issuing so many follow-on messages, and then revisit later when we think we can do better about being more targeted in these error reports to things we think are likely real problems. We decided having nightly diverge from beta behavior was a bad idea. |
|
Does anyone have a kind of standalone example of this? |
|
I spent a few minutes trying to make one and failed. |
|
Nonetheless it seems clear that the recovery in #31555 is at fault. So maybe we can modify the logic there -- but it'd be great to have some kind of test, so that we have some idea when we can turn that recovery back on. I'll try to experiment today. I plan to fix the problems in #31997 first, since I have a smaller testcase there. |
|
For the record, this is the output I see from @brson's test case: https://gist.github.com/nikomatsakis/b5d93abd92fb30487753 |
This works by adding a method, `fn abort_if_no_parse_recovery`, to the diagnostic handler in `syntax::errors`, and calling it after each error is emitted in the parser. (We might consider adding a debugflag to do such aborts in other places where we are currently attempting recovery, such as resolve, but I think the parser is the really important case to handle in the face of rust-lang#31994 and the parser bugs of varying degrees that were injected by parse error recovery.)
This works by adding a boolean flag, `continue_after_error`, to `syntax::errors::Handler` that can be imperatively set to `true` or `false` via a new `fn set_continue_after_error`. The flag starts off true (since we generally try to recover from compiler errors, and `Handler` is shared across all phases). Then, during the `phase_1_parse_input`, we consult the setting of the `-Z continue-parse-after-error` debug flag to determine whether we should leave the flag set to `true` or should change it to `false`. ---- (We might consider adding a debugflag to do such aborts in other places where we are currently attempting recovery, such as resolve, but I think the parser is the really important case to handle in the face of rust-lang#31994 and the parser bugs of varying degrees that were injected by parse error recovery.)
…ebugflag, r=nrc Gate parser recovery via debugflag Gate parser recovery via debugflag Put in `-Z continue_parse_after_error` This works by adding a method, `fn abort_if_no_parse_recovery`, to the diagnostic handler in `syntax::errors`, and calling it after each error is emitted in the parser. (We might consider adding a debugflag to do such aborts in other places where we are currently attempting recovery, such as resolve, but I think the parser is the really important case to handle in the face of rust-lang#31994 and the parser bugs of varying degrees that were injected by parse error recovery.) r? @nikomatsakis
This works by adding a boolean flag, `continue_after_error`, to `syntax::errors::Handler` that can be imperatively set to `true` or `false` via a new `fn set_continue_after_error`. The flag starts off true (since we generally try to recover from compiler errors, and `Handler` is shared across all phases). Then, during the `phase_1_parse_input`, we consult the setting of the `-Z continue-parse-after-error` debug flag to determine whether we should leave the flag set to `true` or should change it to `false`. ---- (We might consider adding a debugflag to do such aborts in other places where we are currently attempting recovery, such as resolve, but I think the parser is the really important case to handle in the face of rust-lang#31994 and the parser bugs of varying degrees that were injected by parse error recovery.)
In a recent project I had a single typo - failing to close a paren. The error message is below. Remember, there is only one error here, a missing paren. Every single error here is useless. This happens a lot.
The text was updated successfully, but these errors were encountered: