Fix match type instantiation when not approximating

[dwijnand]

When not approximating parameters, keep the constraint entries in a Range, so it can propagate through instantiateParams's ApproximatingTypeMap.

[odersky]

If I understand correctly this will essentially disallow all variable instantiations in the mode canWidenAbstract = true: Wrapping things in a Range produces a MatchResult.NoInstance in redux. So it's

• try first with canWidenAbstract = false and allow to instantiate variables
• if that fails, try with canWidenAbstract = true and disallow to instantiate variables

This is more restrictive than #17180, which still allows to instantiate invariant type variables even if canWidenAbstract = true. It would be good to develop tests that show the difference. I think #17180's neg test already has one such example with Array as the constructor, but we'd have to trry that out on this PR, and also find more examples.

[dwijnand]

Yes, indeed - running locally:

Wrong number of errors encountered when compiling tests/neg/i17149.scala
expected: 1, actual: 2
Unfulfilled expectations:

Unexpected errors:
tests/neg/i17149.scala:16
-> following the errors:
 at 14: Cannot prove that Ext1[T] =:= T.

where:    T is a type in method foo with bounds <: Seq[Any]


Note: a match type could not be fully reduced:

  trying to reduce  Ext1[T]
  failed since selector T
  does not uniquely determine parameter t in
    case Seq[t] => t
  The computed bounds for the parameter are:
    t >: Any
 at 16: Cannot prove that Ext3[A] =:= B.

where:    A is a type in method foo with bounds <: Array[B]


Note: a match type could not be fully reduced:

  trying to reduce  Ext3[A]
  failed since selector A
  does not uniquely determine parameter t in
    case Array[t] => t
  The computed bounds for the parameter are:
    t >: B <: B

[dwijnand]

Actually, as TypeAccumulator is also traversing the type, we do have the variance information to instantiate for invariance.

[odersky]

I think that's still not as precise as the original solution. The original solution says:

Don't widen if the compared-to type contains variant named type parameters

Whereas here we implement a global criterion:

Under mode canWidenAbstract = true, don't instantiate variant named type parameters.

The original proposal would allow the instantiation of variant type parameters if they appear in a part of the pattern that does not correspond to a widened part of the scrutinee. Note: so far we only looked at widening of the scrutinee type as a whole, but one can easily imagine that only subparts are subject to widenings. We need tests for this! The whole thing is woefully under-tested.

It would be really good to work out the theory here. The fact that this is missing in the match type papers and thesis is a big problem.

[dwijnand]

Looking at #17180