Missing bounds check for transparent inline type parameters

[nicolasstucki]

Minimized code

transparent inline def foo[T]: Int = 10
def bar[T]: Int = 10

def test =
  foo[List]
  bar[List]

Output

7 |  bar[List]
  |      ^^^^
  |      Missing type parameter for List

Expectation

The error should also be emitted for foo[List]

[odersky]

Maybe. Not easy to do though, as these type parameters are lost at the time we are allowed to check kinds (can't check early because of risk of cyclic references). So we might also accept this and close.

[nicolasstucki]

Maybe when we inline it we can keep a dummy type Dummy$ = List in the inlined code if T is never referenced which will then fail the check in a later phase.

[odersky]

I'll close this for now. Revisit if someone wants to work on this.

[nicolasstucki]

Another instance of this bug

transparent inline def foo[A <: Int]: Int = valueOf[A]
@main def run = println(foo["hi"])

It should fail but compiles.

[smarter]

Aren't these applications still available in Inlined#call when we do bounds checking?

[nicolasstucki]

Indeed, the call is still there after typer

class Foo:
  transparent inline def foo[A <: Int]: Int = valueOf[A]
  def run = println(foo["hi"])

PackageDef(Ident(<empty>), List(
  TypeDef(Foo, 
    Template(DefDef(<init>, List(List()), TypeTree(), Thicket(List())), List(
      Apply(Select(New(TypeTree()), <init>), List())
    ), ValDef(_, Thicket(List()), Thicket(List())), List(
      DefDef(foo, List(List(
        TypeDef(A, TypeBoundsTree(TypeTree(), Ident(Int), Thicket(List())))
      )), Ident(Int), TypeApply(Ident(valueOf), List(Ident(A))))
    ,
      DefDef(run, List(), TypeTree(), 
        Apply(Ident(println), List(
          Inlined(
+           TypeApply(Select(This(Ident(Foo)), foo), List(
+              SingletonTypeTree(Literal("hi"))
+            ))
          , List(), TypeApply(Ident(valueOf), List(TypeTree())))
        ))
      )
    ))
  )
))

We could check them in post type before removing the call.

[nicolasstucki]

Actually, this should be done in the Inliner just before/after inlining. Otherwise, we could end up losing the inlined tree due o an outer inline method dropping it.

[smarter]

Otherwise, we could end up losing the inlined tree due o an outer inline method dropping it.

If an inlined tree is dropped I assume that's because it's dead code? If so I don't think it's a big deal if we don't check bounds in it since it doesn't affect soundness.

[nicolasstucki]

It is not necessarily dead code. It might be code that a macro used as part of partial evaluation. Hence it was live code during compilation.

[smarter]

I see thanks, can we come up with a test case demonstrating this for #12334 ?