Update: the sbt/sbtn/Windows-only framing below is superseded — the bug reproduces with pure scalac on all platforms. See this comment for the minimized two-stage reproducer and mechanism.
Compiler version
Scala 3.8.3 (Resolver.scalaNightlyRepository).
Minimized code
Self-contained reproduction: https://github.com/soronpo/dottybug/tree/inc_export_cyclic_err (4 source files, 60 lines total).
The abridged cycle:
src/main/scala/stubs.scala has import DFVal.Ops.CarryOp at the top, and defines givens in DFXInt.Ops that reference CarryOp.src/main/scala/DFVal.scala has export DFXInt.Ops.{c1, c2} and defines DFVal.Ops.CarryOp.
That import-export pair is the cycle.
Output
Clean compile (sbtn "clean; compile") succeeds. Then, after touching any unrelated source file (e.g. appending a newline to MutableDB.scala with echo.>> src\main\scala\MutableDB.scala), the next sbtn compile fails:
[error] -- [E046] Cyclic Error: src/main/scala/stubs.scala:31:26
[error] 31 | given c1: ExactOp2Aux[CarryOp, DFC, DFValTP[DFType]] = ???
[error] | ^
[error] | Cyclic reference involving val <import>
The val <import> in the error refers to import DFVal.Ops.CarryOp.
Expectation
Clean and incremental compile should agree — either both succeed or both fail with the same diagnostic. The current behaviour (clean OK, incremental fails) is a spurious error in the incremental path.
Reproduction steps
Windows cmd, from the project root:
sbtn "clean; compile"
echo.>> src\main\scala\MutableDB.scala
sbtn compile
Or run the included repro.bat.
sbtn (thin client) is required so the sbt server state persists between invocations — plain sbt starts a fresh JVM each call and does not reproduce.
Windows-only. Does not reproduce on WSL (Ubuntu). Tested with sbt 1.12.9, Java 17 (Eclipse Adoptium).
Related
Possibly related: #17201 (cyclic reference on exports in package object/top-level) — that issue fires on clean compile and is not Windows-specific.
Compiler version
Scala
3.8.3(Resolver.scalaNightlyRepository).Minimized code
Self-contained reproduction: https://github.com/soronpo/dottybug/tree/inc_export_cyclic_err (4 source files, 60 lines total).
The abridged cycle:
src/main/scala/stubs.scalahasimport DFVal.Ops.CarryOpat the top, and defines givens inDFXInt.Opsthat referenceCarryOp.src/main/scala/DFVal.scalahasexport DFXInt.Ops.{c1, c2}and definesDFVal.Ops.CarryOp.That import-export pair is the cycle.
Output
Clean compile (
sbtn "clean; compile") succeeds. Then, after touching any unrelated source file (e.g. appending a newline toMutableDB.scalawithecho.>> src\main\scala\MutableDB.scala), the nextsbtn compilefails:The
val <import>in the error refers toimport DFVal.Ops.CarryOp.Expectation
Clean and incremental compile should agree — either both succeed or both fail with the same diagnostic. The current behaviour (clean OK, incremental fails) is a spurious error in the incremental path.
Reproduction steps
Windows cmd, from the project root:
Or run the included
repro.bat.sbtn(thin client) is required so the sbt server state persists between invocations — plainsbtstarts a fresh JVM each call and does not reproduce.Windows-only. Does not reproduce on WSL (Ubuntu). Tested with sbt
1.12.9, Java 17 (Eclipse Adoptium).Related
Possibly related: #17201 (cyclic reference on exports in package object/top-level) — that issue fires on clean compile and is not Windows-specific.