Enhance constant-folding during inlining (second try)

[mbovel]

#24431 was reverted in #25703. This PR restores #24431.

Fixes #24420 and fixes #24412.

[sjrd]

An ascription that doesn't pass that condition is an invalid ascription. How does it even get there?

[mbovel]

An ascription that doesn't pass that condition is an invalid ascription. How does it even get there?

It turns out you can generate malformed trees with macros. See #25690 for more 😅

[sjrd]

Right. Then the macro needs to be fixed.

[mbovel]

Right. Then the macro needs to be fixed.

Sure, that's why I opened the PR on ZIO to enable -Xcheck-macros and hopefully find the problem. But for now that just triggers another compiler crash.

In the meantime, and in case other codebases rely on broken macros, don't you think that defensively checking the assertion is valid would make sense?

[mbovel]

See also the internal Slack discussion about -Xcheck-macros: https://lampepfl.slack.com/archives/C06FYNL1WDT/p1775647016206789.

[sjrd]

don't you think that defensively checking the assertion is valid would make sense?

No, it really doesn't make sense. You can't pollute every other place of the compiler with dealing with bad stuff that macros generate. It's not sustainable. In this case it might run on the JVM because it inserts casts to heal things, but not on JS, whose backend is stricter.

At most, you could have a postprocessing after a macro that turns bad ascriptions into casts. And emits a warning in the process. At least the blast radius of that hack would be limited to macros.

[mbovel]

I filled zio/zio#10721, let's see if I can get some help fixing this in ZIO directly.

PR also opened: zio/zio#10725.

[mbovel]

@WojciechMazur, I made zio/zio#10725 on ZIO to avoid #25690 and #25692, and leviysoft/oolong#61 on Oolong to avoid #25697, so I hope the open community build can now pass on this change. Could you please update ZIO and Oolong in the open community build, and then run it on this PR?

[WojciechMazur]

Could you please update ZIO and Oolong in the open community build, and then run it on this PR?

Sure, just be aware I can force these 2 to be used from main branch instead of latest release, but when it comes to zio the problem was in majority present for the users of their macros - I cannot safely force zio dependency upgrade for these, as it might lead to other, unrelated compilation errors. Effectively their builds might be broken until they upgrade to latest version of ZIO

[mbovel]

Could you please update ZIO and Oolong in the open community build, and then run it on this PR?

Sure, just be aware I can force these 2 to be used from main branch instead of latest release, but when it comes to zio the problem was in majority present for the users of their macros - I cannot safely force zio dependency upgrade for these, as it might lead to other, unrelated compilation errors. Effectively their builds might be broken until they upgrade to latest version of ZIO

Ah, I see, thanks for the explanation. So I guess I need to wait until both ZIO and Oolong release new versions.

[mbovel]

@WojciechMazur ZIO just released 2.1.26 with my fix 🥳
And for Oolong, my fix is included in v0.5.1.

Could we try running the community build on this PR, with these updated versions?

[mbovel]

If I understand correctly, the open community build actually uses the latest releases by default.

So it might pass now, modulo projects that might use older versions of ZIO, as Wojciech mentioned above.

Solal launched a community build run for me:

• https://github.com/VirtusLab/community-build3/actions/runs/26022227786
• https://github.com/VirtusLab/community-build3/actions/runs/26022230016.

Wait and see.

[mbovel]

Results: https://scala3.westeurope.cloudapp.azure.com/dashboard/compare?baseScalaVersion=3.9.0-RC1-bin-20260508-eb2e041-NIGHTLY&targetScalaVersion=3.9.0-RC1-bin-20260510-bbd3d41.

It shows 88 new failing projects, but it seems a lot of them are not related to this PR 🤔

[mbovel]

@WojciechMazur: the community build took oolong 0.5.0, while the latest version on Scaladex and Maven central is 0.5.2. Do you know why? That's actually the only new failure caused by a compilation error.

The other 87 new failures are due to tests failing. It's still not clear to me how these are related to this PR.

[WojciechMazur]

the community build took oolong 0.5.0, while the latest version on Scaladex and Maven central is 0.5.2. Do you know why?

It caused by problems with our Scaladex scrapping, resulting in project configs not being updated. I'm fixing it right now

[mbovel]

@WojciechMazur, ping me when I can try to run the open community build again 🙂

[WojciechMazur]

There are conflicts in the presentation compiler build - once it's fixed we can shcedule a new OpenCB
I've rebased the branch previously so we can have an up to date results and compare against latest nightlies reliably

[WojciechMazur]

OpenCB results against 08.07.2026 nightly (last one) https://scala3.westeurope.cloudapp.azure.com/dashboard/compare?baseScalaVersion=3.10.0-RC1-bin-20260707-a4dab1a-NIGHTLY&targetScalaVersion=3.10.0-RC1-bin-20260708-66263c2&reason=Compilation
Seems to be no new regressions, but be aware that revently there was a regression introduced on main that caused ~80 failures and was not fixed yet, so there might be a false-negatives in this comparsion

[mbovel]

Thanks a lot!
Do you think we should wait for the regression on main to be fixed then, or merge this PR already?

[mbovel]

I see no regression in pekko or zio-dependent libraries, so I think we can try to merge and see if we get any regressions in the next nightlies.

[SolalPirelli]

It looks okay to me but I'm not the right person for inlining stuff, maybe @jchyb ?

[mbovel]

It looks okay to me but I'm not the right person for inlining stuff, maybe @jchyb ?

Sure, but you already approved that exact changes set in #24431, that's why I asked you 😄

[SolalPirelli]

Ah I forgot this PR had history... okay given the previous discussion I guess people are okay with it.

[SolalPirelli]

I'm rebasing because main is already broken and we shouldn't break it further so let's wait til that's fixed to merge this.

[Gedochao]

(rebased)

[WojciechMazur]

@mbovel Regression reproducer for kitlangton/neotype, do you think it must be fixed in the library or can be resolved in compiler?

// macro.scala

import scala.quoted.*

abstract class Newtype[A]:
  opaque type Type = A

  inline def apply(inline input: A): Type =
    ${ Newtype.applyImpl[A, Type]('input) }

object Newtype:
  def applyImpl[A: Type, T: Type](input: Expr[A])(using Quotes): Expr[T] =
    // Same cast neotype uses after (optional) compile-time validation.
    input.asExprOf[T]

//> using file macro.scala

type NonEmptyString = NonEmptyString.Type
object NonEmptyString extends Newtype[String]

type FullName = FullName.Type
object FullName extends Newtype[NonEmptyString]

@main def Test(): Unit =
  val fullName: FullName = FullName(NonEmptyString("Bob Smith"))
  println(fullName)

yields

Compiling project (Scala 3.10.0-RC1-bin-20260718-b17ee7a-NIGHTLY, JVM (25))
[error] ./test.scala:19:28
[error] Macro expansion has type String, which does not conform to the expected type NonEmptyString
[error]   val fullName: FullName = FullName(NonEmptyString("Bob Smith"))
[error]                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error compiling project (Scala 3.10.0-RC1-bin-20260718-b17ee7a-NIGHTLY, JVM (25))

Potential fix:
replace input.asExprOf[T] with

object Newtype:
  def applyImpl[A: Type, T: Type](input: Expr[A])(using Quotes): Expr[T] =
    import quotes.reflect.*
    Typed(input.asTerm, TypeTree.of[T]).asExprOf[T]

however it feels like that can be something compiler can do for us instead. There was no issues under -Xcheck-macros before

[mbovel]

@WojciechMazur the fix is the same as in https://github.com/scala/scala3/pull/25731/changes#diff-1afc6b9cbf71fc548e1526eea8be0e3420423fd7da2485caebd5473f055ac125; use an asInstanceOf in the generated code, not at the meta level:

// macro.scala

import scala.quoted.*

abstract class Newtype[A]:
  opaque type Type = A

  inline def apply(inline input: A): Type =
    ${ Newtype.applyImpl[A, Type]('input) }

object Newtype:
  def applyImpl[A: Type, T: Type](input: Expr[A])(using Quotes): Expr[T] =
    // Same cast neotype uses after (optional) compile-time validation.
    '{$input.asInstanceOf[T]}

There is a crucial phase distinction here:

• Performing an unsafe cast in the generated code is fine.
• Performing an unsafe (and illegal) cast at the meta level, on quotes, must be a hard error. Otherwise, we would authorize an ill-typed tree in the compiler.

Previously, -Xcheck-macros did not report an error because this check was missing. However, allowing such casts resulted in compiler crashes.