`clearCaches` only reset the in-memory session caches (compiler cache,
classloader cache, and file-cache stores) carried over from sbt 1, so none of
the action caches introduced in sbt 2 were actually cleared despite the help
text saying otherwise. The only way to remove the action cache was `cleanFull`,
which also wipes `target/out` entirely, including build outputs and the command
history.
`clearCaches` now additionally deletes, while respecting `cleanKeepFiles` and
`cleanKeepGlobs`:
- the contents of every local `DiskActionCacheStore` (the `cas/` and `ac/`
directories under `localCacheDirectory`)
- the materialized task-value files under `target/out/value`
- symbolic links under `target/out` that point into a cleared store, which
would otherwise be left dangling
Build outputs, the command history, and the boot directory are preserved.
Ordering and robustness details:
- The in-memory caches are reset before the on-disk stores are deleted, so
files those caches may still hold open (e.g. jars referenced by cached
classloaders) are released before their deletion is attempted. On Windows an
open handle otherwise makes the underlying file undeletable.
- `target/out` references (symlinks) are deleted before the cas blobs they
point at.
- Deletions retry on transient `IOException` (as `DiskActionCacheStore#syncFile`
already does for writes) and, instead of being silently swallowed, any file
that still cannot be deleted is reported: per-path at warn level, with the
summary downgraded from "cleared" to "partially cleared".
The `clearCaches` help text is updated to describe the new behavior, and a
scripted test (`cache/clear-caches`) covers it. The test records a baseline of
existing store entries and asserts only that the entries it creates are cleared,
so unrelated blobs left behind by other tests sharing the batch sandbox are out
of scope.
Failure caching assumes a CompileFailed is a function of
the sources, which is true for source errors. But zinc also surfaces I/O write
failures ("error writing X.class") as compiler problems, so an environmental
failure (a concurrent target/ deletion, a permission blip) was cached under the
same mechanism and replayed from the global action cache on every later build,
even after the cause was gone. When the poisoned task is the metabuild compile
this is self-sustaining and unrecoverable from inside sbt: project loading
fails, so no task -- including clean -- can run, and only deleting the global
cache by hand recovers. The replayed diagnostics also name files/permissions
that no longer exist.
Refs #9455
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
**Problem**
sbt 2.x currently constructs the test classloader using symlinks
to the JARs in CAS (content-addressable storage).
This causes issues because JVM apparently caches opened JAR files by path,
and since the symlink itself doesn't change it could end up
serving stale resource files.
**Solution**
We can workaround this issue by resolving the symlinks to the real path.
The ivyless-publish-http and ivyless-publish-http-plugin scripted tests
defined publishToHttp as three unordered `.value` dependencies
(startPublishServer, publish, stopPublishServer). sbt evaluates task
dependencies before the task body in an unspecified order, so publish
could run before the HTTP server was listening and fail intermittently
with "Connection refused". It is reproducible under CPU contention (a
2-vCPU runner), which is why it began flaking on the JDK-25 shard and
turned develop red.
Use Def.sequential to guarantee start -> publish -> stop ordering, the
way the sibling ivyless-publish-maven-http test already sequences via
separate scripted commands.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The thin client (sbtn) parsed the launcher value flags (-java-home, -mem,
-jvm-debug, -sbt-dir, ...) but then dropped them. The space form was consumed
and discarded; the flag=value form fell through to the residual arguments and
was forwarded to the server verbatim, where --java-home=/path was rejected as a
command (`Not a valid command: --`).
When the client had to start a server (none running, no --server), the consumed
-java-home never reached the forked sbt launcher, so the server came up under
the default JVM and, in CI where the intended JDK is only reachable via
-java-home, failed to connect.
parseArgs now captures the consumed launcher value flags (both `flag value` and
`flag=value`) into Arguments.launcherValueArgs, and the cold-start fork re-passes
them to the sbt launcher so the server runs under the requested JVM. The client
tokenizes arguments by splitting on whitespace, which would otherwise fragment a
value that contains spaces (a Windows path like C:\Program Files\Java); parseArgs
tracks those split boundaries and rejoins a value flag's value. An empty flag=
value and a dangling flag with no value are consumed but not propagated, since
the launcher's require_arg would otherwise fail the fork.
The fork command construction is extracted into a pure, package-visible
serverCommand so a test can assert the propagated flag reaches the started
server. The sbt-launch-jar path is unchanged: it invokes java directly, with no
launcher to interpret the flag.
Fixes#9418
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem:
When useIvy := false, ivyless publishing dropped the optional
scala_[scalaVersion]/ and sbt_[sbtVersion]/ path segments from Ivy-style
plugin publish patterns. This caused sbt 1 plugins published from sbt 2 builds
to land under non-plugin Ivy paths, so consumers looking under
scala_2.12/sbt_1.0/ could not resolve them.
Solution:
Read the plugin cross-version attributes from the CsrProject module and use
them when constructing ivyless Ivy-layout publish paths. Apply the same
substitution for local/file Ivy publishing and remote Ivy-style URL publishing,
while continuing to omit those optional segments when the attributes are absent.
Add scripted regressions for local and HTTP Ivy-style publishing of an sbt 1
plugin with useIvy := false.
A task that floods stdout could not be stopped promptly: cancelling it
(Ctrl+C from the thin client) stopped the task, but the server kept
draining the already-queued output to the client for several seconds,
because onCancellationRequest never discarded the pending backlog.
onCancellationRequest now sets a per-channel isCanceled flag and clears the
queued frames and buffered stdout (discardPending), and jsonRpcNotify
drops the cancelled task's systemOut/systemErr while the flag is set, so
output stops promptly.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
NetworkChannel batches writes to the client at most once per 20ms to
reduce terminal flicker and byte volume. forceFlush(), used to order
buffered stdout ahead of a control-plane message, called
flushExecutor.shutdownNow() -- the only place the executor was ever
shut down. Once it ran during active output it tore the executor
down (and, if a coalesced flush was pending, cancelled its future
without resetting flushFuture, leaving the slot stuck), so the 20ms
coalescing was gone for the rest of the connection: stdout was then
flushed per write via the inline fallback instead of batched. Output
still reaches the client, so the effect is extra flushes rather than
lost output, but shutting the shared executor down on the first
forceFlush is clearly unintended.
Extract the flush state machine into CoalescingFlusher. forceFlush now
drains immediately and leaves the timer live (a pending coalesced
drain harmlessly drains the remainder when it fires); the executor is
shut down once, at channel teardown, so it no longer leaks. doFlush
now holds a lock across both the drain and the publish so an inline
forceFlush and the timer's drain can't deliver two stdout batches out
of order.
Fixes#9415
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The byteStreamStub lazy val applied withDeadlineAfter once, baking in an
absolute deadline that was reused for the store's whole (session-long)
lifetime. remoteTimeoutInSec after the first blob transfer, every later
ByteStream read/write was rejected with DEADLINE_EXCEEDED, so the remote
cache could neither upload nor download blobs >chunkSizeBytes for the rest
of the sbt server's life.
Derive a fresh stub with the deadline per RPC so each call gets its own
relative timeout.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Any IOException while creating the boot io socket was wrapped in
ServerAlreadyBootingException and reported as "sbt thinks that server
is already booting" with a stack trace, and non-interactive
invocations exited with code 2. Permission or path-length problems
with XDG_RUNTIME_DIR or the temp directory and Windows named-pipe
access errors all hit this, blocking sbt entirely (#6777). Raw
IOExceptions from the constructor (socket directory creation) were
not caught at all and crashed startup.
getSocketOrExit now connects to the socket (BootServerSocketProbe,
shared with the test suite) to check for a live server before
believing the exception.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
**Problem**
sbt runner script defaults to sbtn, even on the operating system
where sbtn is not available.
**Solution**
This fallbacks to the jvm client.
This applies a range of optimisations local to ClassStamper that bring the time needed for refinedTestDigests down to acceptable levels (see #9108):
* Cache the digests of transitive dependencies (big impact)
* Avoid sorting of digest subsets that would later get sorted again (small)
* Pre-compute which Analysis instances are required for each class to avoid repeated scanning of the whole list (medium)
* Merge two loops on relations.externalDeps into one (small)
* Compute the set of extra digests outside loop (small)
* Track the digest closure of each test via a BitSet (big)
**Problem**
Global plugin loading doesn't work.
**Solution**
1. Use ModuleID from to supply the location of global-plugin module.
2. Update pluginData with the global plugin classpath.
- Use Builders to avoid building intermediate collections
- Use a mutable.Set for alreadySeen
- Use plain Set instead of SortedSet
- Sorting only needs to happen at the end of the computation in transitiveStamp
Job ids are long. The job id parser currently uses NotSpace to parse the ids, which fails with a NumberFormatException for short non-numeric values and OOMs SBT for long non-numeric values.
**Problem**
Test is based on https://github.com/sbt/sbt/issues/9345#issuecomment-4718229113 which gives us the following sequence:
1. Metals sends buildTarget/compile.
2. sbt publishes real non-empty diagnostics.
3. Metals sends buildTarget/scalaMainClasses.
4. During that request, sbt emits build/publishDiagnostics with diagnostics: [] and reset: true.
5. The following build/taskFinish still reports errors: 1.
Previously, errors for diagnostics reporting via bsp were collected from a live compilation run. In the sequence above, that is triggered by buildTarget/compile. Then, buildTarget/scalaMainClasses does not trigger such a run for the second time, it uses the cached compilation result. Therefore, the diagnostics is not populated.
**Solution**
The proposed fix modifies sendFailureReport to accept an optional CompileFailed object that contains the diagnostics even in case the actual compiler did not run because the cached result was used. If no problems were found for a file via default means, this CompileFailed object is queried to see if it has any information about problems in a given file.
Problem
When build.properties contains whitespaces like sbt.version = 1.12.12, parsing fails and the detected sbt version falls back to 2.0.0.
Solution
Trim whitespaces in build.properties.
Def.setting and Def.task macro expansion looks for internal wrapper
call generated for .value.
It visits all function calls in the macro. If the block contains
functions call whose type parameter is HKT, macro expansion crashed.
Macro expansion tries to match IO against '[a], and failed with MatchError.
This commit adds wildcard pattern, and leave unmatched type arguments unchanged.
In a project with multiple main classes, the "multiple main classes detected" warning is unwanted noise when running tests. This message is already suppressed for explicit run commands, now also suppress it for test.
Kevin Lee
kenji yoshida
BrianHotopp
eugene yokota
Anatolii Kmetiuk
Yannick Heiber
Matt Dziuban
Merlin Hughes
Rikito Taniguchi