Fix exhaustivity uncheckableType's logic for tuples

[dwijnand]

As tuples (e.g. Tuple2) are case classes, for which enumerateSubtypes
returns List(List(tp)) therefore making it "checkable", any tuple type
was accidentally always passing (or at least it has since that isCase
branch was added to enumerateSubtypes). This was leading to false
positives in the exhaustivity checking, as a tuple of non-sealed types
was being deemed inexhaustive with a wildcard (_, _) counter-example.

Fixes scala/bug#10373

[dwijnand]

(Not hugely release-note-able, but perhaps it can be linked as a minor fix in the same area.)

[lrytz]

Why do we have special treatment of tuples in the first place?

If I define my own T2 tuple case class, the example gives

<console>:26: warning: match may not be exhaustive.
It would fail on the following input: T2((x: Foo forSome x not in (Foo_1, Foo_2)), _)
           def blitz(that: Foo): Unit = T2(this, that) match {
                                          ^

also after this PR. Is that expected?

[dwijnand]

Why do we have special treatment of tuples in the first place?

Not 100% sure - because it was common and was fixed to do something appropriate, I guess? Then it broke 😄

also after this PR. Is that expected?

Not in my eyes.

[dwijnand]

I can't put together a generalisation of this for any case class (i.e. any Product extending class). I think this is, again, tied to null: if we didn't disable the null modelling (like patmat's Logic was original built to) I think it would say It would fail on the following input: T2(null, _) instead, and (null, _) for tuples.

So I'm going to stop here. I'm happy for this to be merged, merged but keeping scala/bug#10373 open for the T2 custom case class, merged and opening another ticket for T2, or closed without merging.

[lrytz]

👍 happy to merge this fix. Can you log a new ticket for the custom case class case?