Skip to content

fix: compile-check does not record a compile whose inputs changed while it ran - #3330

Merged
hatayama merged 1 commit into
feature/compile-check-changed-files-checkfrom
fix/compile-check-recheck-key-before-recording
Oct 15, 2026
Merged

hatayama merged 1 commit into
feature/compile-check-changed-files-checkfrom
fix/compile-check-recheck-key-before-recording

Conversation

@hatayama

@hatayama hatayama commented Oct 15, 2026 •

Copy link
Copy Markdown
Owner

Summary

  • compile-check no longer reuses a compile result that was recorded for different file contents. Before this change, a source edited while csc was compiling could make a later run report what the edited file had reported, even after the file was put back.

User Impact

  • To reproduce before this change:
    1. Edit a source to content X and run compile-check.
    2. While csc compiles that assembly, edit the source to Y.
    3. Put the source back to X and run again.
    4. The second run reuses the first compile and reports Y's diagnostics: errors that X does not have, or no errors where X has some.
  • With this change, the second run compiles the assembly again and reports what X really has.

Changes

  • The input key is computed before csc starts, but csc reads the sources while it compiles. The compile result was recorded under the key computed before the compile, so an edit during the compile was recorded under the key of the bytes before it.
  • The key is now computed again just before the compile result is recorded. When it no longer matches, the result still answers this run, but nothing is recorded. The compile already removed the previous record, so the next run compiles again.
  • The baseline for the changed-files check is unchanged. It already detects edits made during the compile and says so in FastPathBaselineNotes. That step still runs after a compile whose key moved, so its note is not lost.
  • One visible consequence: after a compile during which an input other than the source contents changed, the next run's fallback reason changes. It used to be no baseline: the last full compile did not record one; it is now no baseline: no full compile of this assembly is on record, because no compile is on record. The note of the run that compiled still names the input that changed. Before this change the next run compiled in full as well, since the leftover record was under another key and could never be reused. The compile-check doc says so where it lists that reason, and where it describes edits made during a compile.
  • Cost: one more input-key computation per compiled assembly. It reads that assembly's sources and the references this run produced again.

Verification

  • New test: an edit made during the compile and then reverted compiles again instead of being reused. Without the fix it is reused (0 compiles).
  • TestNonSourceInputChangedDuringCompileLeavesNoBaseline now expects the reason above, and its comment says the compile leaves no record to reuse either.
  • Mutations, each restored afterwards:
    • Always recording fails the new test and the test above.
    • Never recording fails every reuse test, including TestCompileUnitsReusesEveryUnitWhoseInputsDidNotMove.
  • cli/dispatcher:
    • golangci-lint fmt --diff is empty; go vet ./... passes; golangci-lint run and the complexity config both report 0 issues.
    • go test ./... and go test -race ./internal/compilecheck/... pass.
    • Coverage with the CI exclusions: 94.24% (baseline 94.2).
  • cli/release-automation: go test ./... passes. The file-length check passes.

View guided diff

@coderabbitai

coderabbitai Bot commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration
  • Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 3905b2ef-9411-4a31-ad67-d49810ba8955
📥 Commits

Reviewing files that changed from the base of the PR and between f46b2a4 and 87bd6aa.

📒 Files selected for processing: 13
  • Packages/src/Editor/CliOnlyTools~/CompileCheck/Skill/SKILL.md
  • cli/dispatcher/internal/compilecheck/compiler.go
  • cli/dispatcher/internal/compilecheck/fast_path.go
  • cli/dispatcher/internal/compilecheck/fast_path_fixture_test.go
  • cli/dispatcher/internal/compilecheck/fast_path_replay_test.go
  • cli/dispatcher/internal/compilecheck/fast_path_test.go
  • cli/dispatcher/internal/compilecheck/input_key.go
  • cli/dispatcher/internal/compilecheck/result_cache.go
  • cli/dispatcher/internal/compilecheck/scheduler_cache_test.go
  • cli/dispatcher/internal/dispatcher/compile_check.go
  • cli/dispatcher/internal/dispatcher/compile_check_fast_path_test.go
  • docs/adr/0015-compile-check-checks-only-changed-files-after-a-full-compile.md
  • docs/compile-check.md
+----------------------------------------------+
| Winning the war on bugs, one line at a time. |
+----------------------------------------------+
  \
   \     /)/)
        ( '')
        /  |
      o(___)
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Base automatically changed from feat/compile-check-replay-fast-check to feature/compile-check-changed-files-check October 15, 2026 04:20
…le it ran

The compile result was recorded under the input key read before csc started, but
csc reads the sources while it compiles. An edit made during the compile was
therefore recorded under the key of the bytes before it, and putting the file
back reused what the edited file reported. The key is now read again before
recording, and a compile whose key moved leaves no record, so the next run
compiles again.

After a compile whose inputs changed while it ran, the next run's fallback
reason is now that no full compile is on record, since none is; the note of
the run that compiled still names the input.
@hatayama
hatayama force-pushed the fix/compile-check-recheck-key-before-recording branch from 87bd6aa to 2ef5ac7 Compare October 15, 2026 04:21
@hatayama
hatayama merged commit eb7989a into feature/compile-check-changed-files-check Oct 15, 2026
3 checks passed
@hatayama
hatayama deleted the fix/compile-check-recheck-key-before-recording branch October 15, 2026 04:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant