Drop "no inlines with opaques" implementation restriction

[odersky]

Fixes #12814

[odersky]

A more positive fix of the problem would drop the implementation restriction that inline methods cannot be defined where opaque types are visible.

But it looks as hard as ever. Expanding inlines will render code type-incorrect as #12814 shows. We only eliminate opaque types some 20 phases later (after that the program would be type-correct again). And we cannot move elim opaques earlier since RefChecks assumes that opaque types are still opaque.

[soronpo]

Instead of restricting inlines completely, maybe just disallow the automatic "casting" to the opaque within the inline?
If I use an opaque type to create a new type Positive and I have an inline method that verifies the value, there is no reason I shouldn't be able to use .asInstanceOf instead:

opaque type Positive <: Int = Int
object Positive:
  inline def apply(inline value : Int) : Positive = 
    inline if (value <= 0) compiletime.error("must be positive")
    else value.asInstanceOf[Positive]
  inline def justAnotherInlineDef : Unit = ??? //this is also disallowed :-(

Ideally, we wouldn't want asInstanceOf[Positive], but this is a far better restriction than eliminating any inline definition within the scope of an opaque.

[smarter]

But it looks as hard as ever.

We've briefly discussed before if we could handle opaques in inline by giving a more precise type to the this-proxy we generate, but I don't think anyone has actually tried it so far. Taking #12814 as an example, we get after inlining:

        val nine: refined.Positive = 
          {
            val PositiveFactory_this: refined.Positive.type = refined.Positive
            PositiveFactory_this.f(x):refined.Positive
          }

If we could instead generate:

  val nine = {
    val r1: refined.type & { type Positive = Int } = refined.asInstanceOf[ refined.type & { type Positive = Int }]
    val PositiveFactory_this: r1.Positive.type = r1.Positive
    PositiveFactory_this.f(x)
  }

Then the expansion would typecheck.

[odersky]

@smarter I did a first test with your idea which worked! So I want to follow up on this approach before merging this PR.

[smarter]

This branch is never actually reached for pos/opaque-inline1.scala, it is reached for pos/opaque-inline.scala but at that point expansion0.tpe and call.tpe are both refined.Positive so the cast doesn't do anything (and the test passes if I delete it).

[smarter]

Minor point: we could check the accessibility of alias at this point to generate a slightly better error message if it isn't accessible, but the current one isn't too bad:

object refined:
  private class Internal(x: Int)
  opaque type Positive = Internal
  inline def Positive(value: Int): Positive = new Internal(value)

object test:
  def run: Unit =
    val x = 9
    val nine = refined.Positive(x)

-- Error: tests/pos/opaque-inline1.scala:10:31 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 |    val nine = refined.Positive(x)
   |               ^^^^^^^^^^^^^^^^^^^
   |               class Internal cannot be accessed as a member of (refined : refined.type{Positive = refined.Internal}) from module class test$.
   | This location contains code that was inlined from opaque-inline1.scala:4

[odersky]

There was a wrong condition for eliding the proxies, which is fixed in 2414033. Now pos/opaque-inline1 does not compile anymore if I remove the cast. It fails in -Ycheck with

java.lang.AssertionError: assertion failed: Found:    Int
Required: refined.Positive
found: class Int in package scala with class Int, flags = final abstract <scala-2.x> <touched>, underlying = Int, AnyVal {...}
expected: type Positive in object refined with type Positive, flags = <deferred> opaque <touched>, underlying = refined.Positive, , Any, {...}
tree = {
  val $proxy1: refined.type{Positive = Int} = 
    refined.$asInstanceOf[refined.type{Positive = Int}]
  val refined$_this: ($proxy1 : refined.type{Positive = Int}) = $proxy1
  refined$_this.f(x):refined$_this.Positive
} while compiling opaque-inline1.scala

The weird thing is that with the original condition everything succeeded, even though the expansion was then

  val x = 9
  val nine = refined.f(x): refined.Positive

This is clearly type-incorrect, since 9 is an Int and refined.f expects a refined.Positive. Indeed, if I write this expansion manually, it fails.

-- [E007] Type Mismatch Error: opaque-inline1.scala:12:25 ----------------------
12 |    val nine = refined.f(x): refined.Positive
   |                         ^
   |                         Found:    (x : Int)
   |                         Required: refined.Positive

But somehow -Ycheck does not test this. I traced Ycheck's behavior and it seems to think that refined.f: Int => Int even though it should be refined.f: Positive => Positive. The reason for this is that it copies the tree refined.f as is from the inline method, which is in a scope where Positive = Int. Hence, Int => Int is a legal type for f there. It's the copying that is wrong, and unfortunately Ycheck does not catch it.

But the case won't arise anymore with this PR.

[johnynek]

you can also write:

opaqueProxies
  .collectFirst { case (from, to) if from.symbol == ref.symbol && from =:= ref => to }

and I think not have two lambdas.

[odersky]

Thanks for the hint. I'll change it.

[smarter]

🎆