Unused warning with transparent inline

charpov · March 29, 2025, 3:03pm

This is a followup to Matching on a context function.

Using @Jasper-M 's help, I was able to implement what I need, namely a withThreads context that runs code on an implicit thread pool but behaves differently whether that code produces a future or not.

This demo application (available at GitHub - charpov/UnusedWarning: A confusing Scala warning; the warning disappears if Test2 is uncommented.) produces an interesting warning:

package foo

import tinyscalautils.threads.{ Execute, withThreads }

@main def Test1() =
   withThreads():
      Execute(println("X"))

/*
def Test2() =
   withThreads():
      scala.concurrent.Future(println("X"))
 */

sbt run executes the program but produces this warning:

[warn] /.../UnusedWarning/S/src/main/scala/tinyscalautils/threads/withThreads.scala: unused local definition

Note that:

The message refers to a non-existing local directory and to a source file from the library where withThreads is implemented.
Uncommenting Test2 makes the warning disappear.

Further investigation shows the warning to refer to this code:

transparent inline def _withThreads[A](n: Int, awaitTermination: Boolean)(
    code: ExecutionContextExecutorService ?=> A
) =
   val f = exec => code(using exec)
   inline f match
      case g: (ExecutionContextExecutorService => Future[?]) =>
         _withThreadsAndWait(n, awaitTermination)(g)
      case _ =>
         _withThreadsAndWait(n, awaitTermination)(exec => { code(using exec); Future.unit })

and the warning is:

[warn] 117 |   val f = exec => code(using exec)
[warn]     |       ^
[warn]     |       unused local definition

What seems to be happening is that if withThreads is used somewhere with a future, the first case is matched and f is considered being used. However, if all uses of withThreads are with non-future code, only the second case is used and f is considered unused.

This feels buggy. It’s confusing to get warnings in an application that refers to (inlined) code from a library. Also, f is clearly used (and needed) in the body of _withThreads.

(As a workaround, I think I can rewrite code(using exec) into f(exec) in my library to convince the compiler that f is being used in the second case; that seems to make the warning go away.)

som-snytt · March 29, 2025, 5:12pm

-Vprint:typer,inlining to show the expansion:

[info] package foo {
[info]   import tinyscalautils.threads.{Execute, withThreads}
[info]   final lazy module val Test$package: foo.Test$package = new foo.Test$package()
[info]   final module class Test$package() extends Object() {
[info]     this: foo.Test$package.type =>
[info]     @main def Test1(): Unit =
[info]       {
[info]         val code$proxy1:
[info]           (scala.concurrent.ExecutionContextExecutorService) ?=> Unit = (using
[info]           contextual$1: scala.concurrent.ExecutionContextExecutorService) =>
[info]           tinyscalautils.threads.Execute.apply[Unit](println("X"))(contextual$1)
[info]         {
[info]           val code$proxy2:
[info]             (scala.concurrent.ExecutionContextExecutorService) ?=> Unit = (
[info]             using evidence$5: scala.concurrent.ExecutionContextExecutorService)
[info]              => code$proxy1.apply(evidence$5)
[info]           {
[info]             val f: scala.concurrent.ExecutionContextExecutorService => Unit = (
[info]               exec: scala.concurrent.ExecutionContextExecutorService) =>
[info]               code$proxy2.apply(exec)
[info]             tinyscalautils.threads._withThreadsAndWait[Unit](0, false)((
[info]               exec: scala.concurrent.ExecutionContextExecutorService) =>
[info]               {
[info]                 code$proxy2.apply(exec)
[info]                 scala.concurrent.Future.unit
[info]               }
[info]             )
[info]           }
[info]         }
[info]       }
[info]   }

The val f is unused.

In current 3.7, it does not warn about the expansion, but soon there will be a compiler option to choose what to warn about, similar to -Wmacros in Scala 2.

Your Test2 looks different:

[info]     def Test2(): Unit =
[info]       {
[info]         val code$proxy3:
[info]           (scala.concurrent.ExecutionContextExecutorService) ?=>
[info]             scala.concurrent.Future[Unit]
[info]          = (using contextual$2: scala.concurrent.ExecutionContextExecutorService
[info]           ) => scala.concurrent.Future.apply[Unit](println("X"))(contextual$2)
[info]         {
[info]           val code$proxy4:
[info]             (scala.concurrent.ExecutionContextExecutorService) ?=>
[info]               scala.concurrent.Future[Unit]
[info]            = (using evidence$5: scala.concurrent.ExecutionContextExecutorService
[info]             ) => code$proxy3.apply(evidence$5)
[info]           {
[info]             val f:
[info]               scala.concurrent.ExecutionContextExecutorService =>
[info]                 scala.concurrent.Future[Unit]
[info]              = (exec: scala.concurrent.ExecutionContextExecutorService) =>
[info]               code$proxy4.apply(exec)
[info]             {
[info]               val $scrutinee2:
[info]
[info]                   (f : scala.concurrent.ExecutionContextExecutorService =>
[info]                     scala.concurrent.Future[Unit])
[info]
[info]                = f
[info]               val g:
[info]                 scala.concurrent.ExecutionContextExecutorService =>
[info]                   scala.concurrent.Future[Unit]
[info]                = $scrutinee2
[info]               tinyscalautils.threads._withThreadsAndWait[Unit](0, false)(g)
[info]             }
[info]           }
[info]         }
[info]       }

I did not look at what you’re attempting, but I see that f and g are “used”.

charpov · March 29, 2025, 8:10pm

Thanks (again) for the compiler options (I need to write them down once and for all…).

Yes, that’s consistent with my intuition. However, that leaves my questions unanswered:

Users (e.g., my students) see a warning that refers to a source file that’s not theirs in a directory that doesn’t exist. There isn’t much they can do about it.
So, the responsibility is mine on the definition site of the macro. What should I do? Mark f as @unused, even though it is conceptually used before the inlining? Would that even work? Or am I implementing withThreads the wrong way? I use transparent inline to get the right return type (from Future[A] to A and from non-future types to Unit), but maybe there’s another way?

som-snytt · March 30, 2025, 5:48am

I neglected to reference the open ticket:

github.com/scala/scala3

Some warnings in inlined code show up at the callsite

opened 09:47AM - 13 Mar 25 UTC

lrytz

itype:bug itype:question area:reporting area:inline

Some warnings in inlined code show up at the callsite, some don't. It depends on… the compiler phase in which the warning is issued. That seems arbitrary. For example, this definition triggers two warnings: ```scala scala> inline def foo = { 1; Stream(1).head } 2 warnings found -- [E129] Potential Issue Warning: --------------------------------------------- 1 |inline def foo = { 1; Stream(1).head } | ^ | A pure expression does nothing in statement position | | longer explanation available when compiling with `-explain` -- Deprecation Warning: -------------------------------------------------------- 1 |inline def foo = { 1; Stream(1).head } | ^^^^^^ |value Stream in package scala is deprecated since 2.13.0: Use LazyList instead of Stream def foo: Int ``` One of them shows up when using the inline method: ```scala scala> foo 1 warning found -- Deprecation Warning: -------------------------------------------------------- 1 |inline def foo = { 1; Stream(1).head } | ^^^^^^ |value Stream in package scala is deprecated since 2.13.0: Use LazyList instead of Stream val res0: Int = 1 ``` The recent https://github.com/scala/scala3/pull/22682 makes sure that messages filtered by `@nowarn` in the inline def don't leak to the callsite. But does it ever make sense to see warnings in inlined code? Should that be configurable with a flag?

I assume that will be addressed under the aegis of “how to warn about Inlined expansions”. (What knob to press or pull, what to report.)

For student use of 3.6.4, -Wconf:msg=regex, but the message doesn’t have enough information.

Perhaps in future, the origin of the diagnostic will specify what was inlined.

I wonder if msg matches the whole “explanation” when -explain is turned on. Often a message will report that there was code inlined from a file.

Adding @nowarn annotations to inline code, as in your item 2, works only recently. Adding @unused may already work in 3.6, where it issues a warning only if a problem is detected both times the check runs (after typer and again a few phases later).