summonInline in a function in a quoted block causes compiler crash

[KuceraMartin]

Compiler version

3.3.1, 3.4.0-RC1-bin-20240109-91db06a-NIGHTLY-git-91db06a

Minimized code

// main.scala

trait SomeImplicits:
  given int: Int

def fn: Unit =
  Macro.testSummon

// macro.scala

import scala.quoted.*
import scala.compiletime.summonInline

object Macro:

  transparent inline def testSummon = ${ testSummonImpl }

  private def testSummonImpl(using Quotes): Expr[SomeImplicits => Int] =
    import quotes.reflect.*
    '{
      (x: SomeImplicits) =>
        import x.given
        summonInline[Int]
    }

Output (click arrow to expand)

``` unhandled exception while running pickler on /Users/martin/development/macro-test/main.scala An unhandled exception was thrown in the compiler. Please file a crash report here: https://github.com/lampepfl/dotty/issues/new/choose For non-enriched exceptions, compile with -Yno-enrich-error-messages. while compiling: /Users/martin/development/macro-test/main.scala during phase: pickler mode: Mode(ImplicitsEnabled) library version: version 2.13.12 compiler version: version 3.4.0-RC1-bin-20240109-91db06a-NIGHTLY-git-91db06a settings: -classpath /Users/martin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.4.0-RC1-bin-20240109-91db06a-NIGHTLY/scala3-library_3-3.4.0-RC1-bin-20240109-91db06a-NIGHTLY.jar:/Users/martin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.12/scala-library-2.13.12.jar -d /Users/martin/development/macro-test/.scala-build/macro-test_3200b05eac-8a7bba9ae5/classes/main -java-output-version 17 -sourceroot /Users/martin/development/macro-test Exception while compiling /Users/martin/development/macro-test/main.scala, /Users/martin/development/macro-test/macro.scala An unhandled exception was thrown in the compiler. Please file a crash report here: https://github.com/lampepfl/dotty/issues/new/choose For non-enriched exceptions, compile with -Yno-enrich-error-messages. while compiling: during phase: parser mode: Mode() library version: version 2.13.12 compiler version: version 3.4.0-RC1-bin-20240109-91db06a-NIGHTLY-git-91db06a settings: -classpath /Users/martin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.4.0-RC1-bin-20240109-91db06a-NIGHTLY/scala3-library_3-3.4.0-RC1-bin-20240109-91db06a-NIGHTLY.jar:/Users/martin/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.12/scala-library-2.13.12.jar -d /Users/martin/development/macro-test/.scala-build/macro-test_3200b05eac-8a7bba9ae5/classes/main -java-output-version 17 -sourceroot /Users/martin/development/macro-test Exception in thread "main" java.lang.AssertionError: assertion failed: unresolved symbols: parameter x (line 10) #32164 when pickling /Users/martin/development/macro-test/main.scala at scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:8) at dotty.tools.dotc.core.tasty.TreePickler.pickle(TreePickler.scala:863) at dotty.tools.dotc.transform.Pickler.run$$anonfun$1$$anonfun$1(Pickler.scala:125) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at scala.collection.immutable.List.foreach(List.scala:333) at dotty.tools.dotc.transform.Pickler.run$$anonfun$1(Pickler.scala:180) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at scala.collection.immutable.List.foreach(List.scala:333) at dotty.tools.dotc.transform.Pickler.run(Pickler.scala:180) at dotty.tools.dotc.core.Phases$Phase.runOn$$anonfun$1(Phases.scala:354) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at scala.collection.immutable.List.foreach(List.scala:333) at dotty.tools.dotc.core.Phases$Phase.runOn(Phases.scala:360) at dotty.tools.dotc.transform.Pickler.runOn(Pickler.scala:197) at dotty.tools.dotc.Run.runPhases$1$$anonfun$1(Run.scala:315) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15) at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10) at scala.collection.ArrayOps$.foreach$extension(ArrayOps.scala:1323) at dotty.tools.dotc.Run.runPhases$1(Run.scala:337) at dotty.tools.dotc.Run.compileUnits$$anonfun$1(Run.scala:348) at dotty.tools.dotc.Run.compileUnits$$anonfun$adapted$1(Run.scala:357) at dotty.tools.dotc.util.Stats$.maybeMonitored(Stats.scala:69) at dotty.tools.dotc.Run.compileUnits(Run.scala:357) at dotty.tools.dotc.Run.compileUnits(Run.scala:267) at dotty.tools.dotc.Driver.finish(Driver.scala:58) at dotty.tools.dotc.Driver.doCompile(Driver.scala:38) at dotty.tools.dotc.Driver.process(Driver.scala:197) at dotty.tools.dotc.Driver.process(Driver.scala:165) at dotty.tools.dotc.Driver.process(Driver.scala:177) at dotty.tools.dotc.Driver.main(Driver.scala:207) at dotty.tools.dotc.Main.main(Main.scala) Compilation failed ```

[mbovel]

This issue was picked for the Issue Spree of March 19th, 2024. @EugeneFlesselle, @KuceraMartin, @nmcb will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[nicolasstucki]

Issue might be the same as in #19493

[lihaoyi]

@Gedochao @EugeneFlesselle any updates here? This is blocking https://github.com/com-lihaoyi/scalasql from supporting Scala 3, which in future would block a number of experiments around using named tuples etc. to model database queries and the like

[EugeneFlesselle]

any updates here?

I'm still working on it -- and am pretty familiar with was is going wrong -- but I am yet to find a way to fix it.

This is blocking https://github.com/com-lihaoyi/scalasql from supporting Scala 3

Maybe this is obvious but just in case, the situation that fails is one where summonInline isn't needed, so it could be replaced with a normal summon; unless it is necessary for it to be able to resolve an implicit from both the ctx of the caller and the ctx of the body, depending on usages.

[lihaoyi]

Thanks @EugeneFlesselle ! As long as you're working on it that's fine, just worried it got dropped.

As far as I know, we needed summonInline in order to resolve implicits from the context of the caller