Repository navigation
fix(swift): record the target distro in lockfile entries - #11299
Conversation
Swift publishes a different Linux tarball per distro (`ubuntu24.04`, `fedora39`, `ubi9`, `amazonlinux2`, …), but nothing about the distro reached the lockfile: entries were keyed by a bare `linux-x64` with no options. An entry written on Ubuntu therefore matched exactly on Fedora, and its checksum was verified against the Fedora tarball — a mismatch no mise command could resolve, since `mise lock` wrote nothing for `core:swift` and silently kept the old distro's checksum when an entry already existed. - `core:swift` now reports the distro as a lockfile option (`swift_platform`), the same way `core:erlang` records `precompiled_os`, so each distro gets its own entry and changing `swift.platform` produces a new one instead of reusing a checksum for a different artifact. - `core:swift` resolves lock info, so `mise lock` records the URL each entry describes rather than writing nothing. swift.org publishes no checksum sidecar, only a detached signature, so the checksum is still filled in at install time. Locking a musl target now fails instead of recording a URL that doesn't exist. - Swift's URL construction is target-aware, so cross-platform locking no longer labels another machine's platform with the host's distro. A target that isn't the current machine falls back to Ubuntu — the only distro with Linux arm64 builds. - An entry written before the distro was recorded keeps its version pin but has its artifact data ignored, so existing lockfiles neither lose their pin nor assert a checksum for an unknown distro. - `mise lock` reports resolutions that wrote no entry as skipped instead of counting them as updates. A backend that can't resolve metadata without installing returns empty info, which is `Ok` but produces no entry — that read as "✓ 2 platform entries (0 skipped)" over an untouched lockfile. - Checksum mismatches now name the lock entry the expectation came from, including its options and locked URL, so a distro mismatch is visible in the message instead of looking like a corrupt download. Reported in #11295 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughSwift lockfiles now record distro-specific artifact options, distinguish exact host entries, support legacy version-only entries, improve artifact verification metadata, and report only written lock entries. Tests and documentation cover distro switching and fallback behavior. ChangesSwift lockfile identity
Sequence Diagram(s)sequenceDiagram
participant User
participant ToolRequest
participant Lockfile
participant SwiftPlugin
User->>ToolRequest: lock Swift for target
ToolRequest->>SwiftPlugin: resolve lockfile options
SwiftPlugin-->>ToolRequest: swift_platform and target URL
ToolRequest->>Lockfile: find exact or legacy entry
Lockfile-->>ToolRequest: selected version and platform data
ToolRequest->>SwiftPlugin: verify artifact
SwiftPlugin-->>Lockfile: checksum and size metadata
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c189dbb. Configure here.
Greptile SummaryThis PR makes Swift lockfile entries distro-aware and improves lock resolution behavior.
Confidence Score: 5/5The PR appears safe to merge. The previous target URL issue is resolved because Linux distro pins are no longer applied to macOS or Windows targets, and constructed artifact URLs must pass an HTTP status check before they can be recorded; no blocking failure remains. Important Files Changed
Reviews (2): Last reviewed commit: "fix(swift): apply the distro pin only to..." | Re-trigger Greptile |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
e2e/lockfile/test_lockfile_swift_distro (1)
39-58: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAssert the legacy checksum is actually dropped.
The legacy-entry case verifies the version pin survives and that a new distro entry appears, but nothing asserts the core regression — that the unattributable checksum isn't carried into the
ubi9entry. Aassert_not_containson that blake3 hash in the new entry (or on the whole file after relock) would pin the behavior this PR exists to fix.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@e2e/lockfile/test_lockfile_swift_distro` around lines 39 - 58, The lockfile regression test around the legacy Swift entry must verify that the unattributable legacy checksum is removed, not merely that the version and ubi9 entry remain. After relocking with `mise lock swift --platform linux-x64`, add an assertion using the existing checksum hash and `assert_not_contains` against the rewritten lockfile (or new entry), while preserving the current version and distro-entry assertions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/plugins/core/swift.rs`:
- Around line 336-345: Update platform() so the Settings::get().swift.platform
override is applied only when target.os_name() is Linux; inspect the target
before returning the configured platform. Preserve the existing macOS and
Windows mappings and linux_platform fallback for non-overridden targets,
ensuring non-Linux targets never inherit the Linux distro setting.
---
Nitpick comments:
In `@e2e/lockfile/test_lockfile_swift_distro`:
- Around line 39-58: The lockfile regression test around the legacy Swift entry
must verify that the unattributable legacy checksum is removed, not merely that
the version and ubi9 entry remain. After relocking with `mise lock swift
--platform linux-x64`, add an assertion using the existing checksum hash and
`assert_not_contains` against the rewritten lockfile (or new entry), while
preserving the current version and distro-entry assertions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 6a7c57ef-0955-4d65-826a-5ded52960738
📒 Files selected for processing (7)
docs/dev-tools/mise-lock.mde2e/lockfile/test_lockfile_swift_distrosrc/backend/mod.rssrc/cli/lock.rssrc/lockfile.rssrc/plugins/core/swift.rssrc/toolset/tool_request.rs
`swift.platform` names a Linux distro build, but `platform()` returned it for every target before inspecting the OS. With the setting configured repo-wide, cross-platform locking built URLs like `.../ubi9/swift-6.3.1-RELEASE-ubi9.pkg` for macOS — and since the distro option is only recorded for Linux, that URL landed in an option-free entry every macOS host would match. Not every distro/arch pair is published either (`ubi9` has no aarch64 build), and coverage shifts per release, so lock resolution now HEADs the artifact rather than encoding a matrix that would go stale. A platform that isn't published is reported as skipped instead of recording a URL that 404s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Addressed the review feedback in 5e04e13 — all three bots flagged the same real bug, thanks.
Distro/arch pairs that aren't published (Greptile's second half — The discussion's repro with I looked at recording Unit suite 1923 passing, This comment was generated by an AI coding assistant. |
Hyperfine Performance
|
| Command | Mean [ms] | Min [ms] | Max [ms] | Relative |
|---|---|---|---|---|
mise-2026.7.13 x -- echo |
18.4 ± 2.6 | 16.4 | 34.8 | 1.00 |
mise x -- echo |
19.2 ± 1.8 | 17.3 | 50.9 | 1.04 ± 0.18 |
mise env
| Command | Mean [ms] | Min [ms] | Max [ms] | Relative |
|---|---|---|---|---|
mise-2026.7.13 env |
17.1 ± 0.7 | 15.8 | 20.0 | 1.00 |
mise env |
17.8 ± 0.8 | 16.4 | 21.1 | 1.04 ± 0.06 |
mise hook-env
| Command | Mean [ms] | Min [ms] | Max [ms] | Relative |
|---|---|---|---|---|
mise-2026.7.13 hook-env |
17.8 ± 0.8 | 16.4 | 21.6 | 1.00 |
mise hook-env |
18.7 ± 0.9 | 17.3 | 23.1 | 1.05 ± 0.07 |
mise ls
| Command | Mean [ms] | Min [ms] | Max [ms] | Relative |
|---|---|---|---|---|
mise-2026.7.13 ls |
15.1 ± 0.7 | 13.9 | 18.8 | 1.00 |
mise ls |
15.8 ± 0.8 | 14.4 | 20.3 | 1.05 ± 0.07 |
xtasks/test/perf
| Command | mise-2026.7.13 | mise | Variance |
|---|---|---|---|
| install (cached) | 153ms | 165ms | -7% |
| ls (cached) | 57ms | 58ms | -1% |
| bin-paths (cached) | 59ms | 62ms | -4% |
| task-ls (cached) | 126ms | 129ms | -2% |

Reported in #11295.
The problem
Swift publishes a different Linux tarball per distro (
ubuntu24.04,fedora39,ubi9,amazonlinux2, …), but nothing about the distro reached the lockfile — entries were keyed by a barelinux-x64with no options. Two bugs followed:Cross-distro checksum failures. An entry written on Ubuntu matched exactly on Fedora (same key, both option-free), so the Ubuntu checksum was verified against the Fedora tarball. The error named the downloaded filename and two digests with nothing to suggest a distro mismatch.
mise lockreported success while writing nothing.core:swiftimplements noresolve_lock_info, so it fell through toresolve_lock_info_fallback, which returns an all-NonePlatformInfo. That'sOk, so the run counted it as an update, butset_platform_infodrops empty info —✓ Updated 2 platform entries (0 skipped)over an untouched lockfile. With an entry already present, the empty info merged as "keep everything", silently preserving the previous distro's checksum. Changingswift.platformtherefore left a project wheremise lockwouldn't re-lock andmise installrejected the artifact the setting selected.The fix
core:erlangalready had this problem — its precompiled builds are per-distro — and solved it with aprecompiled_oslockfile option. Swift now does the same:swift_platformoption oncore:swiftlock entries. Entries are matched on options exactly, so a Fedora machine no longer matches the Ubuntu entry, and changingswift.platformproduces a new entry instead of reusing a checksum for a different artifact.resolve_lock_inforecords the URL each entry describes, somise lockwrites something meaningful. swift.org publishes no checksum sidecar (only a detached.sig), so a checksum still can't be resolved without downloading the ~1 GB toolchain — it's filled in at install. Locking a musl target now errors rather than recording a URL that doesn't exist.Target-aware URL construction, so cross-platform locking stops labeling another machine's platform with the host's distro. A non-current target falls back to Ubuntu, the only distro with Linux arm64 builds.
Legacy entries (written before the distro was recorded) keep their version pin but have their artifact data ignored, so upgrading neither drops an existing pin nor asserts a checksum for an unknown distro. They're also excluded from option rekeying, which would otherwise stamp the local distro's name onto a foreign artifact's checksum.
mise lockaccounting: a resolution that wrote no entry counts as skipped, not as an update. This applies to any backend that returns the empty fallback.Checksum mismatch errors name the lock entry the expectation came from — platform key, options, and locked URL:
Before / after
The discussion's second repro (
swift.platform = "ubi9",mise lock swift --platform linux-x64,linux-arm64) previously produced a lockfile with no platform entries at all. Now:Starting from an Ubuntu-written lockfile and pinning
ubi9,mise locknow creates a separateubi9entry with the right URL and leaves the old entry untouched, instead of silently keeping theubuntu24.04checksum.Testing
src/plugins/core/swift.rs(distro options per target, empty options off Linux, URL resolution for a foreign target, musl rejection, Ubuntu fallback).e2e/lockfile/test_lockfile_swift_distro— covers the distro option, re-locking after changingswift.platform, and a legacy entry keeping its version pin. Locking swift resolves URLs only, so the test never downloads the toolchain.e2e/lockfiletests pass;mise run lintclean.Note
Migration is one-directional but recoverable: an existing option-free swift entry keeps pinning its version, and the first install on each machine writes a distro-labeled entry with the correct checksum. The old entry is preserved rather than rewritten, since there's no way to tell which distro it came from.
🤖 Generated with Claude Code
Note
Medium Risk
Changes lockfile matching, install checksum verification, and Swift download URL resolution across platforms; behavior is well-tested but affects reproducible installs for Swift on Linux.
Overview
Fixes Swift lockfile behavior on Linux where every distro shared the same
linux-x64key, so checksums from one distro were verified against another distro’s tarball.Swift lock entries now carry a
swift_platformoption (e.g.ubuntu24.04,fedora39,ubi9) and are matched on options exactly, so each distro gets its own entry whenswift.platformchanges.resolve_lock_inforecords distro-specific download URLs (HEAD-checked; missing pairs like ubi9 arm64 are skipped; musl fails instead of locking a bogus URL). URL building is target-aware for cross-platformmise lock, with a Ubuntu fallback for foreign Linux targets;swift.platformno longer leaks into macOS/Windows URLs.Legacy option-free Swift entries still pin the version but drop checksum/URL via
without_artifact_data()and skip legacy option rekeying (lockfile_options_are_host_specific).mise lockcounts only entries that actually wrote data (apply_lock_resultreturnsbool); checksum errors name the lock entry (options + URL).Docs and an e2e test cover multi-entry lockfiles and distro changes.
Reviewed by Cursor Bugbot for commit 5e04e13. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit
New Features
Documentation
Bug Fixes