Fix wrong exhaustive check with sequence wildcard on case class with custom unapply

[zielinsky]

Fixes #23459

Based on Scala Lang Spec

[noti0na1]

Shouldn't we disallow this sequence pattern, as there is no unapplySeq in object Test?

[zielinsky]

Hi, thanks, yes!!
I agree this aligns with the spec, and I've updated the PR to emit an error instead of a warning, but I'm a bit concerned about potential backward compatibility for code that may have relied on this being silently accepted.

[noti0na1]

While testing some other examples, I'm surprised that unapplySeq does not work on a companion object of a case class:

case class Test()

object Test:
  def unapplySeq(t: Test): Option[Seq[Int]] = Some(Seq(1, 2))

object TTest:
  def unapplySeq(t: Test): Option[Seq[Int]] = Some(Seq(1, 2))

@main def run(): Unit =
  Test() match
    case Test(x*) => () // error: Wrong number of argument patterns for Test; expected: ()
  Test() match
    case TTest(x*) => ()

[zielinsky]

While testing some other examples, I'm surprised that unapplySeq does not work on a companion object of a case class:

case class Test()

object Test:
  def unapplySeq(t: Test): Option[Seq[Int]] = Some(Seq(1, 2))

object TTest:
  def unapplySeq(t: Test): Option[Seq[Int]] = Some(Seq(1, 2))

@main def run(): Unit =
  Test() match
    case Test(x*) => () // error: Wrong number of argument patterns for Test; expected: ()
  Test() match
    case TTest(x*) => ()

@noti0na1
This happens because for case class Test(), the compiler auto-generates unapply, and trySelectUnapply always tries unapply before unapplySeq. Right now, it reports "Sequence wildcard pattern is not allowed for unapply, only unapplySeq is allowed", which (I think) better explains why the pattern is rejected.

[Gedochao]

Bump @noti0na1