Commits on Mar 30, 2016

1. 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 rust-lang#31994 and the parser bugs of varying degrees that were
   injected by parse error recovery.)

   

   pnkfelix committed Mar 30, 2016
   Configuration menu

   • View commit details
   • Copy full SHA for 2646663
   • Browse repository at this point

   Copy the full SHA

   2646663 View commit details

   Browse the repository at this point in the history

2. fix compile-fail and parse-fail tests by blindly opting back into …

   parser recovery (so that expected errors match up)
   
   I'm opting into parser recovery in all these cases out of expediency,
   not because the error messages you get with recovery enabled are
   actually all that usable in all cases listed.

   

   pnkfelix committed Mar 30, 2016
   Configuration menu

   • View commit details
   • Copy full SHA for e1d8ad3
   • Browse repository at this point

   Copy the full SHA

   e1d8ad3 View commit details

   Browse the repository at this point in the history