handle recoverable submod parse errors correctly #4200
Conversation
| @@ -0,0 +1,6 @@ | |||
| fn foo() { | |||
There was a problem hiding this comment.
I elected to stash the test files in a new directory under tests (parser) since they're explicitly testing for fatal errors during formatting as opposed to our typical integration/idempotence tests.
I'm open to another directory name and/or location, but I do think it's important to have negative scenario tests like this to help give us better protection against upstream changes in rustc parsing and prevent any regressions.
| sess.reset_errors(); | ||
| if sess.can_reset_errors() { | ||
| sess.reset_errors(); | ||
| } |
There was a problem hiding this comment.
I'm not sure if this (and the similar change in parse_mod_items below) could cause any unintended side effects.
The only use case I could think of would be an instance where rustfmt is seeing, and deliberately swallowing, a parser error that the rustc parser was unable to recover from. Since this parsing logic is running on all submods now that the rustc parser doesn't parse out-of-line mods, I went ahead and changed this as I can't think of any reason why we would want to ignore such parsing errors.
|
TravisCI failure is spurious and unrelated and has been popping up on several PR's lately |
|
backported in #4253 |
Fixes #4126