Change the way type variables are printed in diagnostics

[ghost]

This PR aims to improve the readability of diagnostic messages that involve unresolved type variables. Currently, messages like the following:

mismatched types: expected `core::result::Result<uint,()>`, found `core::option::Option<<generic #1>>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut <generic #2>`, found `uint`
<anon>:7     f(42u);
               ^~~

tend to appear unapproachable to new users. [0] While specific type var IDs are valuable in
diagnostics that deal with more than one such variable, in practice many messages
only mention one. In those cases, leaving out the specific number makes the messages
slightly less terrifying.

mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_>`
<anon>:6     let a: Result<uint, ()> = None;
                                       ^~~~
mismatched types: expected `&mut _`, found `uint`
<anon>:7     f(42u);
               ^~~

As you can see, I also tweaked the aesthetics slightly by changing type variables to use the type hole syntax _. For integer variables, the syntax used is:

mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1i>`
<anon>:6     let a: Result<uint, ()> = Some(1);

and float variables:

mismatched types: expected `core::result::Result<uint, ()>`, found `core::option::Option<_#1f>`
<anon>:6     let a: Result<uint, ()> = Some(0.5);

[0] https://twitter.com/coda/status/517713085465772032

Closes #2632.
Closes #3404.
Closes #18426.

[ghost]

cc @eddyb

[ftxqxd]

Could you sneak in a fix for the issue where (int,) is formatted like (int)? I was just about to make a fix for this myself but I saw that this PR changes quite a bit of that code anyway.

[ghost]

@P1start Done!

[ghost]

cc @nikomatsakis I figure you may have opinions on this.

[nikomatsakis]

So I think this is great work, though my feeling is that it may be better to just always print _ unless -Z verbose is passed. Have you encountered conditions where knowing the individual identity of the variables was important? I suspect it never comes up; after all, the problem is usually that the variable is never resolved, or else that the known parts cannot be unified (e.g., Option<_> / Result<_,_>).

[nikomatsakis]

One other thing that might be nice and seems like a small tweak on what you have done: in general if the expected/found has the same kind on both sides, or at least it is yielding the same string representation, we could add the message "a different". I'm envisioning something like "found a type parameter, expected a different type parameter". Obviously including the array lengths is even better. Anyway, I'm told this is what the Racket folks do.

[ghost]

@nikomatsakis

Have you encountered conditions where knowing the individual identity of the variables was important?

I was mostly worried about conditions in which the same type variable would appear twice in a diagnostic, like in the example below:

fn foo<T>() -> T { unreachable!() }
pub struct X<T>(T);
pub struct Y<T>(T);

fn main() {
    let mut x = X(foo());
    x = Y(x);
}

<anon>:7:9: 7:13 error: mismatched types: expected `X<<generic #2>>` but found `Y<X<<generic #2>>>` (expected struct X but found struct Y)
<anon>:7     x = Y(x);

And I figured that therefore it could be useful for the user to know that those types are indeed the same variable. Dropping the indices removes that information. I do share the skepticism, though, but would rather lean on the safe side here for now unless you really think we can always drop the IDs?

[nikomatsakis]

@jakub- well, in that example, it's not particularly important that the two variables are the same, is it?

[ghost]

@nikomatsakis Fair enough! I pushed an update that always drops IDs from type vars unless -Z verbose is passed in.

[reem]

I'm concerned about cases where you'd get a message like expected Option<_>, found Option<_> (found _ but expected _) Perhaps if there is more than one _ in the message, it could be #N or _#N?

[ghost]

@reem That is indeed what the PR was implementing and what @nikomatsakis and I were discussing, see above.

In general, it seems that can never happen. The expected/found messages always result from type constraints not being satisfied and it is impossible for two type variables not to satisfy a constraint without at least one of them being partially constrained.

[nikomatsakis]

I think there was consensus that we should not differentiate integral/floating-point/other type variables in the output, as the distinction is not particularly meaningful (though I'd like to see a test where the failure to unify is due to one variable being integral and one being float, e.g.:

let mut x = 1;
x = 2.0;

There was some debate on IRC over _ vs ?. I favor ? at this point, but it's a minor point. I'd like to see the distinction between _#i etc elided, though.

[ghost]

@nikomatsakis I added the tests for (expected ..., found a different ...) as well as integer/float type variable mismatch. r?

[nikomatsakis]

I saw @steveklabnik took your side on irc ;) ok, r+!