rust/src/libsyntax/errors/mod.rs, branch 1.9.0

Put in `-Z continue-parse-after-error`

2016-03-30T20:23:48+00:00

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.)

Implement MultiSpan error reporting

2016-01-28T19:51:06+00:00

This allows to render multiple spans on one line, or to splice multiple replacements into a code suggestion.

The war on abort_if_errors

2016-01-21T19:19:27+00:00

Rollup merge of #30787 - nikomatsakis:future-incompatible-lint, r=brson

2016-01-15T11:58:28+00:00

There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details. Example message: ``` type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum` type-parameter-invalid-lint.rs:14 fn avg(_: T) {} ^ type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)] ^~~~~~~~~~~~~~~~~~~ error: aborting due to previous error ``` r? @brson I would really like feedback also on the specific messages! Fixes #30746

Implement JSON error emission

2016-01-14T21:24:12+00:00

[breaking-change] syntax::errors::Handler::new has been renamed to with_tty_emitter Many functions which used to take a syntax::errors::ColorConfig, now take a rustc::session::config::ErrorOutputType. If you previously used ColorConfig::Auto as a default, you should now use ErrorOutputType::default().

Add an --output option for specifying an error emitter

2016-01-14T21:24:12+00:00

Add a JSON error emitter

2016-01-14T21:20:30+00:00

use fileline_ and not full span_ for the followon messages

2016-01-13T00:38:12+00:00

Revamp the "future incompatible" section to clarify the situation

2016-01-12T17:53:55+00:00

better

Rebasing and review comments

2015-12-30T01:54:36+00:00