Handle binder type symbols in extractor patterns

[liufengyun]

Handle binder type symbols in extractor patterns. Previously the following code will result in two warnings for ConstNullClass and Identity because of the interpolated type symbols _$1, _$2 and T, U don't match:

enum Fun[-T, +U >: Null] {
  def f: T => U = this match {
    case Identity(g) => g
    case ConstNull => (_ => null)
    case ConstNullClass(y) => (_ => null)
    case ConstNullSimple => null
  }

  case Identity[T, U >: Null](g: T => U) extends Fun[T, U]
  case ConstNull
  case ConstNullClass(x: T)
  case ConstNullSimple
}

This PR fixes this problem.

[Blaisorblade]

To be sure: basically this throws away _$1 and _$2, which is fine now but might be less fine if we had type arguments for extractor patterns (which at least I'd like eventually?)

[liufengyun]

If we check according to semantics, I think it's correct. I cannot come up with a counter-example. If some type cannot be checked at run-time, they get a warning instead.

[Blaisorblade]

Yes; since type arguments to classes/traits are erased at runtime, the only use case is for annotating what GADT inference should deduce or for binding type variables generated by GADT inference. For instance:

trait Exp[T]
case class[A, B])[f: Exp[A => B])
def eval[T](e: Exp[T])(env: Env): T = e match {
    case Fun[a, b](x, body) =>
      (v: a) => body.eval(env + (x -> v))
}

[liufengyun]

It seems the example doesn't compile at all, despite any repairing efforts.

[Blaisorblade]

I mentioned upfront the issue is with a potential future feature, so of course my example doesn't work yet:

if we had type arguments for extractor patterns (which at least I'd like eventually?)

[Blaisorblade]

Still uneasy with the strategy, but I guess I should add support for type arguments for extractor patterns before that becomes an issue.

The rest looks reasonable enough.