inline match over Option[String] not accept None as scrutinee

[rssh]

Compiler version

Master on state of Tue Jan 11 00:12:54 EET 2022

Minimized code

object Test {

  inline def get: Option[String] = None

  private transparent inline def fun: Unit =
    inline get match
      case Some(x) => println("value = $x")
      case None    => println("value not set")

  fun

}

Output

[info] compiling 1 Scala source to /Users/rssh/tests/dotty/compileTimeNoCast/target/scala-3.1.2-RC1-bin-SNAPSHOT/classes ...
[error] -- [E007] Type Mismatch Error: /Users/rssh/tests/dotty/compileTimeNoCast/src/main/scala/x/Test.scala:12:2 
[error] 12 |  fun
[error]    |  ^^^
[error]    |  Found:    Option[String]
[error]    |  Required: None.type
[error]    | This location contains code that was inlined from Test.scala:5
[error]    | This location contains code that was inlined from Test.scala:8
[error] one error found
[error] (Compile / compileIncremental) Compilation failed
[error] Total time: 3 s, completed 11 Jan 2022, 00:14:05

Expectation

should be compiled.

[rssh]

// discovered during porting example from #12039. into #14234

[som-snytt]

Where we used to say, "full disclosure", we now say "transparent inline." Without much experience, this seems expected to me.

Also, the elimination of closures ought to be called "disclosure".

[rssh]

slightly minimized:

object Test {

  inline def get: Option[String] = None

  inline def fun: Unit =
    inline get match
      case Some(x) => println("value = $x")
      case None    => println("value not set")

  fun

}

[rssh]

It has supposed to work in April 2021. But yes, expectations can change over time.

[dwijnand]

Without much experience, this seems expected to me.

I likely have the same or less experience with inline semantics, but this doesn't seem expected to me, given the explicit type annotation on get. Now, had get been transparent or declared : None.type or inferred type, then sure, but as it stands I expect it to inline presenting itself as an Option[String].

Is that not how inlining works in general? I.e. is this a match-specific bug?

[bishabosha]

Inline match can only work on the static type of an expression, not its actual "code", so an Option[String] can not be reduced to Some or None. We have discussed several times about looking at the expression instead, but it never went far - again it would be cool to maybe hook into the knowledge that we have FromExpr which could potentially save some work implementing this (apart from not preserving positions).

[SethTisue]

We have discussed several times about looking at the expression instead

I'm interested what that would even mean and what the design implications are.

[dwijnand]

Inline match can only work on the static type of an expression, not its actual "code", so an Option[String] can not be reduced to Some or None.

Ah ok, so this is right to not compile, it just doesn't compile for an accidental reason (the scrutinee binding type mismatches) rather than the real reason (you can't statically reduce an Option in that inline match).

[rssh]

One question left -- why did the original pull request (#12039) passes all tests. So, the inline match was able to statically reduce an Option a few months ago?

[dwijnand]

Perhaps because there envGet is transparent, so using the RHS static type rather than the get static type is expected.

[rssh]

yes, that was it... (Hmm, but port without macros still not possible, because compiletime.error now want constant literal).