Repository navigation
recipes: fork global-input key self-tests - #794
Merged
juliankang4 merged 1 commit intoOct 24, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Verdict: CLEAN: The split preserves key coverage, serial order, and failure reporting.
Checked
- Duplicates: 0 new functions, types, or constants; the existing fixture setup and
_forkedremain the owners. - Complexity: no Rust functions changed; the Python change partitions an existing loop.
- Silent failure: 2 error paths followed. Unknown sections assert; failed child jobs reach the self-test's nonzero exit.
- Tests: independent AST checks confirm all 94 expectation sites are unchanged, unsectioned statement order is preserved, and all five jobs bind their section. The global loop runs only in
globals; the other existing sections are unchanged. The moved assertion protects tools/recipes.py:8966: dropping global key parts leaves unchanged keys and fails the all-items comparison. - Gates: no assertion, threshold, or case removed or relaxed; no PIN moved.
- Escape catalog: no C1–C4 pattern matched. Separate scratch trees and restored edits prevent cross-job interference.
Notes
Dryer and crapper do not apply to this Python-only diff. The full check-recipes suite was not run during validation; checks were structural. The PR reports successful runs before its final rebase, with no full check on the final head.
🔨 Shingler, bloomery's review bot: approves a clean pull request and requests changes on a must-fix (how it works)
Collaborator
Author
|
The review is done and the contribution check passed, so I'm merging this. |
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
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.
check-recipes의 key self-test에서 가장 오래 걸리는 구간을 둘로 나눠 병렬로 돌려, 전체 검사 시간을 줄이는 변경입니다.What and why
key_self_testintools/recipes.pyruns as five forked sections, one persectionvalue. Theinputssection was the longest block ofcheck-recipes, because it also held the loop overKEY_GLOBALS. That loop edits each of the five global inputs in turn and re-analyses every key, one after another, inside theinputsjob.This PR gives the loop its own section,
globals, and adds it to the existing list of forked self-test jobs. The remaininginputschecks stay in their job. Each new fork builds its own scratch tree, manifest and temporaryHOMEthrough the same code path as the other sections. Theinputsguard now wraps the code before the loop and the code after it, so a run without a section (section=None) keeps its old order. The key analysis and cache code are untouched, and no assertion is added, removed or relaxed.Release notes: Under the hood:
check-recipesruns the global-input key self-tests in their own parallel section and finishes sooner.Code shape
_forkedandkey_self_test, and the fixture setup is still written once.sectionassertion still refuses an unknown value; it only gainsglobalsas an allowed one. A failure in the new fork is reported through the existing_forkedpath.cargo fmtandcargo clippy: no Rust changes (one Python file).Duplication found or removed (
path:line), or "none": none.What I ran
Hardware: one Linux x86_64 machine with an AMD Ryzen 5 PRO 6650H and 11 GiB of RAM, no GPU. Both arms ran
bash tools/check-recipes.shpinned to four logical CPUs with four scheduler slots, under CPython 3.12.15 andRUSTFLAGS='-C target-cpu=x86-64-v3'.Main was upstream
c076199f660e1dc10a27885d8488ae42fb0ab7f0and the head was this patch on it. After the measurement, upstream moved and the branch was rebased onto27776a21ffe7364b878c4125a00f3157d71bdc2a. The rebase left the patch unchanged (git range-diffshows=), andtools/recipes.pyis identical in the two bases. Other upstream files, includingtools/check-recipes.sh, did change, so the table below is for the earlier base and I did not measure the full check on the final head.I ran main first and then the head, once each, so this is one pair of observations with no estimate of run-to-run noise. The head ran in a separate session from main, and the two arms were not alternated. Wall time is the time of
static-sched.py run --max 4pluscheck-recipes.sh --reporton the same job list, with the list generation left out.The wall time dropped by 17.606 s, 2.29% [derived]. The self-test block dropped by 67.1 s [derived], but the whole check dropped by much less. The sections run in parallel, so their times do not add up. On the head the other key sections took longer (reach 541 s to 632 s, scope 451 s to 542 s, fixtures 409 s to 491 s, variants 232 s to 271 s), and the last blocks to finish were
pytools.26at 749.7 s andtreecommitat 750.7 s, after the self-test block ended at 701.2 s. I do not claim that the change reduces CPU work: the extra fork repeats one fixture setup.Both arms ran the same 147 block names, all with return code 0 and none skipped. In both,
recipes.py --self-testreports227 gate recipes, 0 failuresand the key CLI self-test reports27 passed, 0 failed.FAIL-first and structure check: a one-off script, not part of this PR, runs the real
jobsexpression ofself_testand evaluates the real section guards. On main it fails withglobal loop routed to inputs: True. On the head it passes, with 94 key assertions whose syntax trees match the original, theKEY_GLOBALSloop identical, the serial order preserved and all five sections dispatched with their own binding. Four planted mutants are each caught: a missingglobalsjob, a lambda that dropssection=section, the loop moved back intoinputs, and the loop's assertion deleted.Not run:
just contrib-check(the CI T0 tier) on the final head,cargo clippyandcargo fmt(no Rust changes), and any GPU gate (no device code changes). The editor diagnostics fortools/recipes.pylist existing Ruff and Pyright findings in the file; none is on a line this PR changes.Reproduction
python3 tools/recipes.py --self-test bash tools/check-recipes.sh --jobs > jobs.tsv python3 tools/static-sched.py run --max 4 --out blocks jobs.tsv bash tools/check-recipes.sh --report blocksRun the last three on main and on the head, and compare the elapsed time of the scheduler run and the report together.
What I ran into
This does not block the PR.
pytools.26andtreecommitblocks decide when the check ends. About 50 s of that tail remains after the self-test block finishes [derived]. Moving those two blocks earlier is a separate scheduling change that I did not try.tools/bloomery/reach_cache.pypreparere-analyses once per root namespace. Reusing a bounded snapshot there could remove some of that repeated work without more forks, but I did not measure it.AI help
AI 코딩 에이전트가 코드를 작성한 후 설명을 썼고, 테스트를 마쳤습니다. diff 리뷰와 PR 초안 리뷰는 제가 직접 했습니다.