Macro-generated match gives an exhaustivity warning, even though it shouldn't

[adamw]

Compiler version

3.0.0-RC3

Minimized example

In a macro, I want to generate a pattern match for a sealed trait/enum, covering each case and performing some actions. The code I've got is the following:

import scala.quoted.*

object MatchTest {
  inline def test[T](inline obj: T): Unit = ${testImpl('obj)}

  def testImpl[T](objExpr: Expr[T])(using qctx: Quotes, t: Type[T]): Expr[Unit] = {
    import qctx.reflect.*

    val obj = objExpr.asTerm
    val cases = obj.tpe.typeSymbol.children.map { child =>
      val subtype = TypeIdent(child)
      val bind = Symbol.newBind(Symbol.spliceOwner, "c", Flags.EmptyFlags, subtype.tpe)
      CaseDef(Bind(bind, Typed(Ref(bind), subtype)), None, '{()}.asTerm)
    }
    val bind = Symbol.newBind(Symbol.spliceOwner, "o", Flags.EmptyFlags, obj.tpe)
    val result = Match(obj, cases)
    println(result.show(using Printer.TreeAnsiCode))
    result.asExprOf[Unit]
  }
}

Tested using:

sealed trait P
case class PC1(a: String) extends P
case class PC2(b: Int) extends P

MatchTest.test(PC2(10): P)

Output

(PC2.apply(10): P) match {
  case c @ (c: PC1) =>
    ()
  case c @ (`c₂`: PC2) =>
    ()
}
[warn] -- [E029] Pattern Match Exhaustivity Warning: Test.scala:25:17
[warn] 25 |  MatchTest.test(PC2(10): P)
[warn]    |                 ^^^^^^^^^^
[warn]    |       match may not be exhaustive.
[warn]    |
[warn]    |       It would fail on pattern case: PC1(_), PC2(_)
[warn]    | This location contains code that was inlined from Test.scala:25

Expectation

I wouldn't expect an exhaustivity warning, as all cases are covered.

I know that the match isn't perfect, but I don't know how to generate a better one. Specifically, instead of c @ (c: PC1), I'd like to generate c @ (_: PC1), but I can't find a way to create a _ using the current macro API. A candidate would be Ident(TermRef(NoPrefix, "_")), but then I don't know how to get a NoPrefix instance.

I also tried adding a third branch with an : Any case, but this didn't help - got the same exhaustivity warning

[liufengyun]

When I compile the snippets with flags:

scalac -d out -Xprint:inlining -Ycheck:all Macro.scalaTest.scala

It ends up with the following expanded tree:

      (PC2.apply(10):P match
        {
          case c @ c:PC1 => ()
          case c @ c:PC2 => ()
        }
      ):Unit

Note that the tree for pattern c @ c: PC1 is different from the desugaring c @ _: PC1 generated by the compiler. Despite that #12190 proposes a fix, I'm not sure if there are other places where the compiler depends on the invariant.

For such use cases, it's recommended to synthesize the code using if/else + isInstanceOf, which is what the pattern match compiles to.

[adamw]

Thanks! Not sure I understand though :) Which invariant you are referring to?

I'd like to generate c @ _: PC1 (or even simply c: PC1), but I don't know how to express it with code in a macro. Or are you saying, that in these cases the macro should if+instanceofs?

[liufengyun]

Which invariant you are referring to? I'd like to generate c @ _: PC1 (or even simply c: PC1), but I don't know how to express it with code in a macro.

Yes, I mean c @ _: PC1 where _ has the type PC1. Yes, the current reflect API does not support creating an Ident like that. I am not sure if it's worth supporting it.

are you saying, that in these cases the macro should if+instanceofs?

Yes, generally it's recommended to avoid generating pattern match code in macros. Macros can use if/else + isInstanceOf to implement the same logic, which works better with the compiler (no complex compiler invariants).

[adamw]

Ah, I see, thanks :) I'll try rewriting that to if-else then

[smarter]

Yes, I mean c @ _: PC1 where _ has the type PC1. Yes, the current reflect API does not support creating an Ident like that. I am not sure if it's worth supporting it.

Given that the reflect API supports creating CaseDef and Bind nodes, I think it makes sense to support wildcards in these nodes too otherwise the API will seem incomplete /cc @nicolasstucki

[nicolasstucki]

Yes, it seems we need to support them in the API. I believed that we could use Idents but it doesn't look like it is possible.

[adamw]

FYI, I rewrote the match to if-else, works fine :) softwaremill/quicklens@503f439