Add SCCACHE_ALLOW_INCREMENTAL to keep caching the non-incremental parts of a build by PHPCraftdream · Pull Request #2810 · mozilla/sccache

PHPCraftdream · 2026-08-17T20:09:54Z

Adds an opt-in SCCACHE_ALLOW_INCREMENTAL=1. Default behaviour is unchanged.

sccache refuses to run when CARGO_INCREMENTAL is set (#1767). That refusal is all-or-nothing, but cargo passes -C incremental= only to workspace members and path dependencies, so the registry dependencies of the same build are still cacheable. With the flag set, the incremental invocations take the CannotCache path compiler/rust.rs has had since 2018, and the rest of the build is cached as before.

CARGO_INCREMENTAL/CARGO_BUILD_INCREMENTAL are no longer hashed into the Rust cache key: they reach rustc only as -C incremental=, already part of the hashed argument list. CACHE_VERSION is not bumped, since this only merges keys whose entries are identical. Entries cached with CARGO_INCREMENTAL explicitly set will miss once.

Tests: the default refusal still fires; with the flag, the registry dep hits an entry written by a non-incremental build while the workspace crate bypasses the cache and gets a real incremental session dir.

Docs: README, docs/Rust.md, docs/Configuration.md.

The second commit is an unrelated clippy::for_kv_map fix I needed locally to get a clean -D warnings run; happy to drop it.

sylvestre · 2026-08-18T13:27:50Z

+            // CARGO_INCREMENTAL/CARGO_BUILD_INCREMENTAL only affect rustc output through
+            // the `-C incremental=` argument cargo derives from them, which is already
+            // hashed as part of the argument list (and marks the invocation non-cacheable
+            // anyway). Hashing the env var too would needlessly fork the cache between
+            // incremental-enabled and incremental-disabled builds of identical deps.
+            // No CACHE_VERSION bump: this only merges previously-distinct keys whose
+            // entries are output-identical (the env var itself does not change rustc
+            // output, and `env!("CARGO_INCREMENTAL")` readers are still tracked through
+            // dep-info env-deps), so existing entries stay valid under the merged key.
            if var == "CARGO_MAKEFLAGS"


do we need such a long comment?

Trimmed to two lines, matching the one-line-per-variable style of the list above it.

sylvestre · 2026-08-18T13:28:19Z

+            // Incrementally compiled crates cannot be cached, so by default
+            // sccache refuses to run at all once cargo enables incremental
+            // compilation, rather than silently returning a useless cache.
+            //
+            // That refusal is all-or-nothing, while incremental compilation is
+            // a property of an individual invocation: cargo passes
+            // `-C incremental=` only to workspace and path crates, so the
+            // registry dependencies of the very same build remain perfectly
+            // cacheable. `SCCACHE_ALLOW_INCREMENTAL` opts into that split.
+            //
+            // Nothing is left unguarded when it is set. compiler/rust.rs has
+            // recognised `-C incremental=` since 2018 and maps it to
+            // `CompilerArguments::CannotCache`, which runs the real compiler
+            // with the original command line and skips caching just that one
+            // request -- the same path already taken by `crate-type`,
+            // `multiple input files` and every other non-cacheable reason,
+            // and still reported as such by `--show-stats`. So the
+            // incremental crates compile incrementally and uncached, while
+            // everything else is cached exactly as before.
+            //
+            // Compared against "1" rather than merely tested for presence (as
+            // SCCACHE_IGNORE_SERVER_IO_ERROR above already does), so that an
+            // opt-in configured globally -- a user environment variable, or
+            // cargo's `[env]` table, which is injected into every wrapper
+            // process cargo spawns -- can still be turned back off for a single
+            // build with SCCACHE_ALLOW_INCREMENTAL=0.


can you please update your agent to not write long comments? thanks

Point taken. Cut to four lines here and trimmed the rest of the PR the same way: 70 lines of added comment removed, 25 kept, code unchanged. The reasoning now lives in the PR description instead.

codecov-commenter · 2026-08-18T13:29:57Z

Codecov Report

❌ Patch coverage is 97.05882% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.20%. Comparing base (f36b89a) to head (d07cd8e).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
tests/sccache_cargo.rs	96.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2810      +/-   ##
==========================================
+ Coverage   73.14%   73.20%   +0.05%     
==========================================
  Files          72       72              
  Lines       37615    37672      +57     
==========================================
+ Hits        27512    27576      +64     
+ Misses      10103    10096       -7

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…ompiles sccache exits with an error as soon as CARGO_INCREMENTAL or CARGO_BUILD_INCREMENTAL is set, because incrementally compiled crates cannot be cached (mozilla#1596, mozilla#1767). That refusal is all-or-nothing, while incremental compilation is a property of an individual invocation: cargo passes `-C incremental=` only to workspace members and path dependencies, so a build's registry dependencies stay perfectly cacheable even when incremental compilation is enabled. Add SCCACHE_ALLOW_INCREMENTAL to opt into that split. The default is unchanged -- without the variable the refusal fires exactly as before, and the error message now points at the escape hatch. With it, the existing per-invocation handling takes over: `-C incremental=` has mapped to CompilerArguments::CannotCache in compiler/rust.rs since 2018, which runs the real compiler with the original command line and skips caching just that one request. That is the same path already taken by `crate-type` and `multiple input files`, and such requests remain visible under "Non-cacheable reasons" in --show-stats. So the workspace crates compile incrementally and uncached, while the rest of the build is cached as usual. Also stop hashing CARGO_INCREMENTAL/CARGO_BUILD_INCREMENTAL into the Rust cache key. They reach rustc only through the `-C incremental=` argument, which is already hashed as part of the argument list, so including them would fork the cache between incremental-enabled and incremental-disabled builds of otherwise identical dependencies and defeat the purpose of the flag. This only merges previously distinct keys whose entries are output-identical, so CACHE_VERSION is not bumped and existing entries stay valid; crates cached while CARGO_INCREMENTAL was explicitly set (e.g. to 0) will see a one-time miss as they move to the merged key. Covered by two integration tests: one asserting the default refusal is still in force, one asserting that with the flag a build populates and then hits the cache for its registry dependency while the workspace crate gets a real rustc incremental session directory.

Fixes a `clippy::for_kv_map` violation that newer clippy reports; the key was already discarded via `_dist_path`.

sylvestre · 2026-08-18T14:29:11Z

similar feedback about comment 0
this is way too long
i am not interested to read a full llm output :(

PHPCraftdream · 2026-08-18T14:38:25Z

Fair. Cut it down to the essentials.

sylvestre reviewed Aug 18, 2026

View reviewed changes

PHPCraftdream added 2 commits August 18, 2026 16:28

clippy: iterate map values directly in disk_mappings

d07cd8e

Fixes a `clippy::for_kv_map` violation that newer clippy reports; the key was already discarded via `_dist_path`.

PHPCraftdream force-pushed the allow-incremental-opt-in branch from 6fe395d to d07cd8e Compare August 18, 2026 14:29

Navigation Menu

Uh oh!

Add SCCACHE_ALLOW_INCREMENTAL to keep caching the non-incremental parts of a build - #2810

Add SCCACHE_ALLOW_INCREMENTAL to keep caching the non-incremental parts of a build#2810
PHPCraftdream wants to merge 2 commits into
mozilla:mainfrom
PHPCraftdream:allow-incremental-opt-in

PHPCraftdream commented Aug 17, 2026 •

edited

Loading

Uh oh!

sylvestre Aug 18, 2026

Uh oh!

PHPCraftdream Aug 18, 2026

Uh oh!

sylvestre Aug 18, 2026

Uh oh!

PHPCraftdream Aug 18, 2026

Uh oh!

codecov-commenter commented Aug 18, 2026 •

edited

Loading

Uh oh!

sylvestre commented Aug 18, 2026

Uh oh!

PHPCraftdream commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

PHPCraftdream commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sylvestre Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

PHPCraftdream Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

sylvestre Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

PHPCraftdream Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

sylvestre commented Aug 18, 2026

Uh oh!

PHPCraftdream commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PHPCraftdream commented Aug 17, 2026 •

edited

Loading

codecov-commenter commented Aug 18, 2026 •

edited

Loading