Fix #1430: Better error messages for type errors involving type variables

[odersky]

Two fixes: (1) Report bounds instead of the variables themselves. (2) Avoid interpolation if there are unreported errors. Also, clean up of error message mentioned in #1424.

Review by @smarter.

[smarter]

The found part could also be improved:

class Inv[T](x: T)
object Test {
  val x: Inv[String] = new Inv(new Inv(1))
}

error: type mismatch:
 found   : Inv[T]
 required: String
  val x: Inv[String] = new Inv(new Inv(1))
                                   ^

[odersky]

@smarter The Inv example is a bit harder because T is invariant. So we cannot approximate with a bound like we did in the previous commit. I'll experiment with an auxiliary clause.

[smarter]

T is invariant but it's also lower-bounded and upper-bounded by Inv[Int] so I don't think an auxiliary clause is necessary there

[odersky]

This has evolved into a rather big refactoring affecting many of the error messages in the compiler. We can now systematically explain ambiguous names and type variables as appendices to error messages. errmsgs.check gives a taste.

[smarter]

Now called em and not d

[smarter]

This is neat, but the disambiguation system should have a special case for aliases, consider:

scala> List[String](List("foo")) 
<console>:5: error: type mismatch:
 found   : scala.collection.immutable.List[String]
 required: String'

where  String   is a class in package lang
       String'  is a type in object Predef$ which is an alias of String

Contrast with scalac:

scala> List[String](List("foo"))
<console>:12: error: type mismatch;
 found   : List[String]
 required: String

[smarter]

(We also need to do something about printing "object Predef$" instead of "object Predef" but that's a separate issue)

[smarter]

We should also look into eliding prefixes (like scala.collection.immutable.List -> List) to avoid this sort of things:

scala> object A { type T = Int; val x: T = "foo" } 
<console>:4: error: type mismatch:
 found   : String("foo")
 required: line18$object.$iw.$iw'.A.T

where  $iw   is a object in object line18$object$
       $iw'  is a object

[smarter]

Probably over-thinking this but instead of T, T', T'', ..., we could use unicode subscripts: T, T₁, T₂, ... which makes it clearer that this is not part of the name of the type. No clue if that works well in the Windows console though.

[smarter]

We could also optionally use different colors for disambiguation :)

[odersky]

@smarter I am open to other ways to indicate variants (color or subscripts are both is nice!) but we should know it works on all terminals.

[odersky]

Rebased to master to avoid merge conflicts.

Any objections to merge this now? Otherwise this PR will be in perennial conflict with everything else that's likely to be committed.

[odersky]

/rebuild

[smarter]

LGTM assuming the tests pass

[felixmulder]

It looks like the CI has stalled on all PRs?

[odersky]

/rebuild

[smarter]

I amended the last commit to force the CI to run again, seems OK now.