Repository navigation
Phase 4: MOS backend sync (cherry-pick/defer against llvm-mos) - #23
Merged
Merged
Conversation
…(Phase 4) Brings patches/llvm/<NN.N>/ up to date with new llvm-mos commits without ever blocking or involving Claude Code (PLAN.md §7.3): lists new llvm-mos commits touching MOS paths since llvm_mos.last_synced, plus anything still in llvm_mos.deferred from a previous run, in chronological order. A "Merge from upstream LLVM" commit is never cherry-picked whole - that drags in llvm-mos's own unrelated upstream-sync history - only its MOS-path diff against its first parent is applied; a regular commit is applied whole, non-MOS files and all, same as the existing patches/llvm/*/0001. Anything that fails to apply, breaks the incremental LLVM build, or breaks a MOS lit test is reverted and deferred. The per-commit incremental build needed a way to get $WORK/llvm-build configured without build-llvm.sh's own base+series invariant, which only holds once per sync-mos-backend.sh run (after regen-patches.sh), not once per candidate commit: factored its cmake invocation into lib.sh's llvm_cmake_configure and added a --configure mode. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sync-mos-backend.yml mirrors sync-rust.yml's structure and auto-merge policy (PLAN.md §10: "MOS backend syncs: auto-merge if all test tiers pass") - fetch/apply, scripts/sync-mos-backend.sh, regen-patches.sh, the full build and all 5 test tiers, PR, auto-merge, release.yml dispatch. Manual for now (workflow_dispatch); watch.yml now dispatches it like sync-rust.yml when WORKFLOW_DISPATCH_TOKEN is set. detect.sh's sync-mos-backend line has no channel (llvm_mos.* is global, not per-channel), so it dispatches for stable; if stable and beta ever sit on different LLVM branches, the maintainer dispatches it for beta by hand. The sync-mos-backend-failure-stable/-beta labels this needs (gh issue-open requires the label to already exist) were created on the repo, the same one-time step Phase 3 already documents for the other workflows' labels. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Summary
scripts/sync-mos-backend.sh: PLAN.md §7.3's cherry-pick-or-defer loop against new llvm-mos commits, never involving Claude Code, never blocking.build-llvm.sh --configure/lib.sh'sllvm_cmake_configure: lets the per-commit loop rebuild$WORK/llvm-buildincrementally withoutbuild-llvm.sh's normal base+series invariant..github/workflows/sync-mos-backend.yml: mirrorssync-rust.yml's auto-merge policy (§10) once the full test suite passes..github/workflows/watch.yml: auto-dispatches the new workflow likesync-rust.ymlwhenWORKFLOW_DISPATCH_TOKENis set.PLAN.md§12 updated with Phase 4's real status.42 llvm-mos commits are currently pending (tracking issue #4): 34 regular + 8 upstream-merge adaptations. Replaying their patches locally against the real
mosbranch (outside the script, no build) hit real conflicts as early as the 1st and 13th candidates, confirming the deferred mechanism is load-bearing from the first run, not a rare edge case.Not validated here: a real incremental LLVM build/lit run (2-core sandbox, impractical). This PR intentionally stays open (not auto-merged) so the first real run of
sync-mos-backend.ymlcan be watched via a manualworkflow_dispatchon this branch before anything merges tomain.Test plan
workflow_dispatchofsync-mos-backend.ymlon this branch (channel=stable) and watch the runwork/sync-mos-backend-report.mdwatch.yml's daily cron take over🤖 Generated with Claude Code