Macro-generated match expression generates a false exhaustivity warning

[arainko]

Compiler version

3.2.1, 3.2.2. 3.3.0-RC2, 3.3.1-RC1-bin-20230127-c0a7d12-NIGHTLY

Minimized code

// file: GeneratedMatchRepro.scala
import scala.quoted.*

object GeneratedMatchRepro {
  inline def generateMatch(tuple: (Option[Int], String)): Option[Int] = ${ generateMatchMacro('tuple) }

  def generateMatchMacro(expr: Expr[(Option[Int], String)])(using Quotes): Expr[Option[Int]] = {
    import quotes.reflect.*
    val optTpe = TypeRepr.of[Option[Int]]
    val strTpe = TypeRepr.of[String]

    val extractor = Select.unique('{ Tuple2 }.asTerm, "unapply").appliedToTypes(optTpe :: strTpe :: Nil)

    val optBind = Symbol.newBind(Symbol.spliceOwner, "opt", Flags.Local, optTpe)
    val strBind = Symbol.newBind(Symbol.spliceOwner, "str", Flags.Local, strTpe)

    val unapply = Unapply(extractor, Nil, Bind(optBind, Wildcard()) :: Bind(strBind, Wildcard()) :: Nil)

    Match(expr.asTerm, CaseDef(unapply, None, Ref(optBind)) :: Nil).asExprOf[Option[Int]]
  }
}

//file: usage.scala

object usage {
  val works1 = GeneratedMatchRepro.generateMatch(Some(1) -> "str")
  val works2 = GeneratedMatchRepro.generateMatch(None -> "str")

  /*warning:
  match may not be exhaustive.

  It would fail on pattern case: (_, _)
   */
  val warns = GeneratedMatchRepro.generateMatch(Option(1) -> "str")

}

Output

match may not be exhaustive.

It would fail on pattern case: (_, _)

Expectation

No exhaustivity warning.

[nicolasstucki]

If we do

    val a = Match(expr.asTerm, CaseDef(unapply, None, Ref(optBind)) :: Nil).asExprOf[Option[Int]]
    val b = '{$expr match
      case (opt, str) => opt: Option[Int]
    }
    println(a.asTerm)
    println(b.asTerm)

we can see that the trees are identical, but b works correctly.

There must be an issue with some type or symbol definition.

[nicolasstucki]

Also, the pattern matcher handles these reflect tuples extraction as generic tuple extraction and not Tuple2. It might be related to the issue of exhaustiveness.

  val works1: Option[Int] =
      {
        val tuple$proxy1: (Some[Int], String) =
          ArrowAssoc[Some[Int]](Some.apply[Int](1)).->[String]("str")
        (matchResult1[Option[Int]]: 
          {
            case val x1: (tuple$proxy1 : (Some[Int], String)) = tuple$proxy1
            if x1.ne(null) then
              {
                case val x2: Any = scala.runtime.Tuples.apply(x1, 0)
                case val x3: Any = scala.runtime.Tuples.apply(x1, 1)
                case val opt: Option[Int] = x2.$asInstanceOf[Option[Int]]
                case val str: String = x3.$asInstanceOf[String]
                return[matchResult1] opt:Option[Int]
              }
             else ()
            throw new MatchError(x1)
          }
        ):Option[Int]
      }

[nicolasstucki]

Workaround warning

+ val matchErrorBind = Symbol.newBind(Symbol.spliceOwner, "x", Flags.EmptyFlags, TypeRepr.of[Any])
+ val matchErrorCase = CaseDef(Bind(matchErrorBind, Wildcard()), None, '{throw new MatchError(${Ref(matchErrorBind).asExpr})}.asTerm)

- Match(expr.asTerm, CaseDef(unapply, None, Ref(optBind)) :: Nil).asExprOf[Option[Int]]
+ Match(expr.asTerm, CaseDef(unapply, None, Ref(optBind)) :: matchErrorCase :: Nil).asExprOf[Option[Int]]

[SethTisue]

I'll be curious to see if there's anything else that could have been done in userspace to troubleshoot this, or whether it truly just needed some compiler hackers to figure it out.

[SethTisue]

We're trying reasoning backwards: looking at the trace from the exhaustivity checker to see how that's going wrong, hoping that will take us directly to what the offending difference in the trees is, and then we can try and figure it out how to prevent that difference from arising.

[SethTisue]

As an aside, note that in normal compilation, the pattern starts life as an Apply, then gets changed to be an UnApply because it's in the context of a pattern match (in Mode.Pattern). Whereas the macro is going straight to the UnApply itself. But that seems correct to do, actually.