Repository navigation
Conversation
retronym
force-pushed
the
claude/1807-bridge-test-on9ml0
branch
from
October 3, 2026 10:31
763402e to
8f89715
Compare
This was referenced Oct 3, 2026
retronym
changed the title
retronym
commented
Oct 5, 2026
| expected, | ||
| sys.error(s"Unknown bridge '$expected', expected one of ${markers.keys.mkString(", ")}") | ||
| ) | ||
| val zip = new java.util.zip.ZipFile(i.compilerBridge.toFile) |
retronym
commented
Oct 5, 2026
| val scala3 = "3.9.0" | ||
| val scala3ForBridge = "3.9.0" | ||
| val scala213ForBridge = "2.13.16" | ||
| val scala213ForBridge = "2.13.18" |
Owner
Author
There was a problem hiding this comment.
justify this change in the PR decription and commit message
retronym
commented
Oct 5, 2026
| ), | ||
| ) | ||
|
|
||
| private val bridgeLabels = List("2.10.x", "2.11.x", "2.12.x", "2.13.x", "2.13.y", "3.x") |
Owner
Author
There was a problem hiding this comment.
Extract constants for these rather than duplicating with above
Scripted picks a bridge by Scala version, and compilerBridgeScala213Bin used scala213, the version of the compiler-bridge sources. So "2.13.y" silently ran on zinc's own bridge. Use scala213ForBridge for it, and fail fast if the two versions are ever equal. Bump scala213ForBridge from 2.13.16 to 2.13.18, the latest 2.13 release (as sbt#1829 also does). sbt compiles 2.13.12 and later with the scala2-sbt-bridge of the project's own Scala version, so "2.13.y" should test the newest stock bridge, which is what current sbt users get. It also gives the two 2.13 bridges different versions, which version-based lookup needs here; the next commit selects bridges by label, after which that is no longer required. Add module-inheritance-extra-hash-213-bin, pending: scala2-sbt-bridge does not report name kinds yet (sbt#1807's bridge side), so `object B extends A` still counts as trait B inheriting A on 2.13 and D recompiles.
A scripted project's scalaVersion ("2.13.x", "2.13.y", ...) now selects
its bridge directly, and the compiler cache and bridge jar are keyed by
that label. So "2.13.x" and "2.13.y" stay apart even when the bridge
sources and scala2-sbt-bridge are built for the same Scala version.
checkBridge asserts which bridge compiles a test, from the package of
CompilerBridge in the bridge jar: zinc's sources (xsbt),
scala2-sbt-bridge (scala.tools.xsbt) or scala3-sbt-bridge
(dotty.tools.xsbt). The general/bridge-* tests use it for each label.
Explain what 2.13.x, 2.13.y and 3.x select, and why the bridge is chosen by label.
All projects in a scripted test share the compiler of the first one that runs a task, so a second scalaVersion was silently ignored. No existing test mixes versions.
retronym
force-pushed
the
claude/1807-bridge-test-on9ml0
branch
from
October 5, 2026 00:17
48fea0b to
17d9651
Compare
Owner
Author
|
Superseded by sbt#1837 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes sbt#1836
Problem
Scripted
build.jsonfiles name a Scala version by label (2.12.x,2.13.y, ...) rather than by patch version, so tests survive Scala upgrades. 46d2131 ("Incorporate Scala 3 binary bridge to scripted") introduced theyand3.xlabels so that scripted can also run against the bridges that ship with the Scala compilers, which are what sbt uses in real builds:2.10.x...2.13.xscala210...scala213compiler-bridgesources2.13.yscala213ForBridgescala2-sbt-bridge(ships with Scala 2.13)3.xscala3ForBridgescala3-sbt-bridge(ships with Scala 3)2.13.yhas never selectedscala2-sbt-bridge. Scripted looks a bridge up by Scala version and takes the first match. ThecompilerBridgeScala213Binproject usedscala213as its version, which is the same string as for the source bridge, so the source bridge always won. When 46d2131 landed,scala213andscala213ForBridgewere both 2.13.13. No scripted test uses2.13.y, so nothing noticed.I found this while backporting sbt#1807 to 1.12.x. Runs I took to be on the stock 2.13 bridge were really on zinc's patched bridge, so the bridge half of sbt#1807 looked unnecessary on 2.13.
A related gap: all projects in a scripted test share the compiler of the first project that runs a task, so a second
scalaVersionin onebuild.jsonwas silently ignored. No existing test mixes versions.Changes
BridgeProviderTestkitkeeps the bridges in a map by label, andIncHandlergets a provider holding only the selected bridge. The compiler cache and the copied bridge jar (target-bridge-<label>.jar) are keyed by label, so2.13.xand2.13.ystay separate even when both are built for the same Scala version. I checked this by setting both to 2.13.16.checkBridge <zinc|scala2-sbt-bridge|scala3-sbt-bridge>asserts which bridge compiled the test. It opens the bridge jar and looks at the package ofCompilerBridge.general/bridge-{2.12.x,2.13.x,2.13.y,3.x}use it, one per label.compilerBridgeScala213Binnow compiles withscala213ForBridge, the version it already fetchesscala2-sbt-bridgeat, so the compiler and the bridge jar always come from the same release. Before, they agreed only because both versions happened to be 2.13.16.scala213ForBridgegoes from 2.13.16 to 2.13.18. That is the current Scala 2.13 release and the version zinc 1.12.x already uses (Run scripted tests on Scala 2.12, 2.13 and 3 sbt/zinc#1829).scala2-sbt-bridgeis the bridge sbt and other build tools load for 2.13.13 and later, so2.13.yshould test the one users get today. The label fix above does not depend on the bump, and no releasedscala2-sbt-bridgereports name kinds, so the pending test below fails the same way on any of them (I ran it on 2.13.17 and 2.13.18).contributing-docs/03_scripted_tests.mddocuments the labels, why2.13.yexists,checkBridge, and the one-version-per-test rule.source-dependencies/module-inheritance-extra-hash-213-binruns the module-inheritance case on the stock bridge. It fails at the lastcheckRecompilations 0 D. Without name kinds,object B extends Acounts as trait B inheriting A, so a private change in A reaches D. Once scala2-sbt-bridge reportsNameKind(retronym/scala#135), the test passes and fails as "pending test passed", which is the cue to remove thependingfile.Testing
The new scripted tests run in CI. Two checks are not in CI, so I ran them as throwaway tests to confirm they fail when they should:
checkBridge scala2-sbt-bridgeon a2.13.xproject:Expected bridge scala2-sbt-bridge (scala/tools/xsbt/CompilerBridge.class), found zinc.build.jsonwith2.13.xand2.13.y:Projects in one scripted test share a compiler, so they must use one scalaVersion: a: 2.13.x, b: 2.13.y. The other tests in the run still pass.