diff options
| author | Felix S. Klock II <pnkfelix@pnkfx.org> | 2016-03-25 18:17:04 +0100 |
|---|---|---|
| committer | Felix S. Klock II <pnkfelix@pnkfx.org> | 2016-03-30 22:23:48 +0200 |
| commit | 2646663b5a9b9bd021e58eb9cd8bcc63b7925c95 (patch) | |
| tree | 072fa5018fa118c757a57653d74750f1fed56b8c /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 40deb279a87e640f799140e9f19b3e64623c30da (diff) | |
| download | rust-2646663b5a9b9bd021e58eb9cd8bcc63b7925c95.tar.gz rust-2646663b5a9b9bd021e58eb9cd8bcc63b7925c95.zip | |
Put in `-Z continue-parse-after-error`
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 #31994 and the parser bugs of varying degrees that were injected by parse error recovery.)
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
