Improve extended errors (rustc --explain).

[michaelsproul]

I've taken another look at extended errors - fixing up the printing and adding a few more for match expressions.

With regards to printing, the previous behaviour was to just print the error message string directly, despite it containing indentation which caused it to overflow the standard terminal width of 80 columns (try rustc --explain E0004). The first approach I considered was to strip the leading whitespace from each line and lay out the text dynamically, inserting spaces in between. This approach became quite messy when taking multi-paragraph errors into account (and seemed overkill). The approach I settled on removes the indentation in the string itself and begins each message with a newline that is stripped before printing.

I feel like complete extended errors would be nice to have for 1.0.0 and I'm happy to spearhead an effort to get them written. Brian got me onto writing them at an SF meetup and I think it shouldn't be too hard to get the remaining 80 or so written with the help of people who don't really work on compiler innards.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[apasel422]

s/can not/cannot/

[pnkfelix]

@michaelsproul Is this commit just changing the code formatting and where the line breaks fall? (Or at least intended to solely to change that?)

Or are there changing to the content mixed in?

Update: Well, clearly ad2e506 has changes to the contents. I guess my question above is solely about commit 19e9828

[michaelsproul]

@pnkfelix: Yeah 19e9828 doesn't change the content at all, it just reflows it in some places.

[pnkfelix]

r=me after the example in ad2e506 is fixed in some manner (see my earlier comment).

[michaelsproul]

Fixed the &Option<u32> thing and adopted the "cannot"s, although I managed to lose your comment in the process of force pushing (whoops).

Thanks for reviewing 😄

[pnkfelix]

@michaelsproul the point from my earlier comment was that i was not sure whether the provided suggested revision was quite right ... although now I see that you have addressed the most important point (that op_num changed its type in the revision), so I guess you probably did see the original comment.

So, okay.

[pnkfelix]

@bors r+ 039a553 rollup

[michaelsproul]

@pnkfelix: Yeah, I think the use of a Copy type makes the op_num example less clear than it could be. Perhaps something like this would serve us better:

// Before.
match Some("hi".to_string()) {
    ref op_string_ref @ Some(ref s) => ...
    None => ...
}

// After.
match Some("hi".to_string()) {
    Some(ref s) => {
        let opt_string_ref = &Some(&s);
        ...
    }
    None => ...
}

This makes a bit more sense, with op_string_ref : &Option<&String>.

If you like this change I could push it and we could approve the new commit before bors jumps on the old one (or it could wait for the next PR).

[brson]

Awesome! This is a really important polish area for 1.0. Anything you can do to stir up more support for this effort would be great.