Wrong match case selected

[Bersier]

Compiler version

3.2.0

Minimized code

class Baz:
  inline def foo: Int = bar(zero)
  inline def bar(inline i: Int): Int = inline i match
    case 0 => 0
    case _ => 1
  private inline def zero = 0

println(Baz().foo)

Output

1

Expectation

0

See also #15893

[prolativ]

This used to work in 3.1.3.
This doesn't work in 3.2.2-RC1-bin-20221025-292e56f-NIGHTLY

[prolativ]

The problem disappears if we replace inline def zero with inline val zero or inline i match with i match

[KacperFKorban]

Minimization without running

class Baz:
  inline def foo: Int = bar(zero)
  inline def bar(inline i: Int): Int = inline i match
    case 0 => 0
    case _ => scala.compiletime.error("XD")
  private inline def zero = 0

@main
def main =
  println(Baz().foo)

[prolativ]

The regressing commit is 86bb972

[odersky]

How important is it? It was @nicolasstucki's commit, and I don't feel confident to propose an alternative. Do we need to revert #15075, reopening the other issue? Or can it wait? It's a difficult tradeoff.

[odersky]

In fact, this should never have worked. Or rather, it does only work if the functions are declared transparent inline. The reason is that

inline def zero = 0

reduces to 0: Int, not 0. And an Int scrutinee cannot distinguish between 0 and not 0.

Otherwise put, if zero could have selected the right match case, then changing the definition of zero to 1 would change the typing if the program. But there's a requirement for normal inline functions that they cannot do that.

[dwijnand]

It's a little confusing to me that "disjointness" is a factor in match type reduction but not in inline matches. Makes it more work to remember the different semantics. I'm guessing it's required or perhaps much preferred.

[odersky]

It's a little confusing to me that "disjointness" is a factor in match type reduction but not in inline matches.

I agree. That's something we should discuss.

[Bersier]

Could someone explain the resolution? Is this behavior as expected? Why does private change the behavior?

[odersky]

It probably should not work with public methods either. There's a grey zone where the inline happens to reduce something because of some optimization or other. We might want to track these down and avoid them at some point, but it's tedious work for not much benefit. But in any case, if the method is not transparent, you can rely only on the result type, which is Int not 0.

[Bersier]

@odersky thank you for clarifying.

A few more observations:

1. This behavior (and how it differs from match type reduction) doesn't currently seem to be fully documented.

2. One might naively assume the inline match to be equivalent to inline if i == 0 then 0 else 1 (but the latter leads to a compile-time error).

3. In both cases, it also seems at odds with the part of the documentation that says It guarantees that inlining actually happens instead of being best-effort. According to that statement, one might naively assume code reduction to proceed somewhat as follows:

class Baz:
  inline def foo: Int = bar(zero)
  inline def bar(inline i: Int): Int = inline if i == 0 then 0 else 1
  private inline def zero = 0

println(Baz().foo)

--> (because zero is guaranteed to be inlined)

class Baz:
  inline def foo: Int = bar(0)
  inline def bar(inline i: Int): Int = inline if i == 0 then 0 else 1

println(Baz().foo)

--> (because bar is guaranteed to be inlined)

class Baz:
  inline def foo: Int = inline if 0 == 0 then 0 else 1

println(Baz().foo)

--> (inline if reduction)

class Baz:
  inline def foo: Int = 0

println(Baz().foo)

--> (because foo is guaranteed to be inlined)

println(0)