Skip to content

endless compilation when deferred inline + match type are used (LTS only) #23110

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
road21 opened this issue May 6, 2025 · 5 comments
Open
Assignees
Labels
area:match-types itype:bug itype:compiler hangs Issues where the compiler hangs. stat:fixed in next The issue was fixed in Next and only still applies to LTS.

Comments

@road21
Copy link
Contributor

road21 commented May 6, 2025

Compiler version

3.3.5 LTS (3.6.4 works as expected)

Minimized code

//> using scala 3.3.5

import scala.compiletime.*

trait InlineFoldR[Acc[_ <: Tuple]]:
  inline def apply[Elem, T <: Tuple](acc: Acc[T]): Acc[Elem *: T]

object InlineFoldR:
  inline def fold[Acc[_ <: Tuple], T <: Tuple](
      acc: Acc[EmptyTuple],
      f: InlineFoldR[Acc]
  ): Acc[T] =
    inline erasedValue[T] match
      case _: EmptyTuple => acc.asInstanceOf[Acc[T]]
      case _: (h1 *: h2 *: h3 *: h4 *: ts) =>
        f[h1, h2 *: h3 *: h4 *: ts](
          f[h2, h3 *: h4 *: ts](
            f[h3, h4 *: ts](f[h4, ts](fold[Acc, ts](acc, f)))
          )
        ).asInstanceOf[Acc[T]]
      case _: (h *: ts) =>
        f[h, ts](fold[Acc, ts](acc, f)).asInstanceOf[Acc[T]]

type DropUnits[A <: Tuple] <: Tuple = A match
  case hd *: tl =>
    hd match
      case Unit => DropUnits[tl]
      case Any  => hd *: DropUnits[tl]
  case EmptyTuple => EmptyTuple

object DropUnits:
  object DropInlined extends InlineFoldR[[T <: Tuple] =>> T => DropUnits[T]]:
    inline def apply[Elem, T <: Tuple](
        acc: T => DropUnits[T]
    ): (Elem *: T) => DropUnits[Elem *: T] =
      (elem: Elem *: T) =>
        inline erasedValue[Elem & Matchable] match
          case _: Unit => acc(elem.tail)
          case _       => elem.head *: acc(elem.tail)

  inline def drop[A <: Tuple](a: A): DropUnits[A] =
    InlineFoldR
      .fold[[T <: Tuple] =>> T => DropUnits[T], A](
        (_: EmptyTuple) => EmptyTuple,
        DropInlined
      )(a)

val a: (
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Int,
    Unit,
    Int,
    Unit
) =
  (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
    1, 1, (), 1, ())

println(DropUnits.drop(a))

Output

Endless compilation

Expectation

Compilation succeeded.

Sorry, I don't know how to minimize it. Deferred inline InlineFoldR and match type DropUnits are required to show the bug.

@road21 road21 added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels May 6, 2025
@tgodzik
Copy link
Contributor

tgodzik commented May 6, 2025

Looks like 3.3.7 nightlies also have the bug, it was probably fixed by something that we haven't been able to port. Anyone knows what that could be?

@WojciechMazur
Copy link
Contributor

Bisect points that it was fixed by 9726e1a
Last nightly with timeout: 3.3.2-RC1-bin-20230630-c629090-NIGHTLY
First nightly that compiles 3.3.2-RC1-bin-20230703-0a21ecf-NIGHTLY

I'm not sure what happen so that it still timeouts in 3.3.2 but compiles with last 3.3.2 nightly: 3.3.2-RC1-bin-20230724-ce1ce99-NIGHTLY
We had no nightlies for 3.3.3
I'll try to bisect between last 3.3.2-NIGHTLY (working) and first 3.3.4-NIGHTLY (failing)

@tgodzik
Copy link
Contributor

tgodzik commented May 7, 2025

We could also just backport #18073 ? I don't see why it wasn't backported.

@WojciechMazur
Copy link
Contributor

We could also just backport #18073 ? I don't see why it wasn't backported.

Be aware that this PR has also caused other regression that remains unfixed to this day. So we're trading here infinite compilations vs unfixed typer regressions. In my opinion the infinite compilation is worse, but still it can affect other projects

@Gedochao Gedochao added itype:compiler hangs Issues where the compiler hangs. area:match-types stat:fixed in next The issue was fixed in Next and only still applies to LTS. and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels May 7, 2025
@Gedochao Gedochao added the stat:needs decision Some aspects of this issue need a decision from the maintainance team. label May 7, 2025
@tgodzik tgodzik removed the stat:needs decision Some aspects of this issue need a decision from the maintainance team. label May 8, 2025
@tgodzik
Copy link
Contributor

tgodzik commented May 8, 2025

Looks like we can't port the fix as it causes a bunch of regressions that are not fixed yet in Next and we need to be more cautious in LTS. Once they are fixed we could try to port the fix, but it's a larger issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:match-types itype:bug itype:compiler hangs Issues where the compiler hangs. stat:fixed in next The issue was fixed in Next and only still applies to LTS.
Projects
None yet
Development

No branches or pull requests

4 participants