Bump Rust toolchain to 1.97.1

[perryqh]

• Moves the pinned toolchain from 1.92.0 to 1.97.1, the current stable release.
• No CI workflow pins a Rust version, so all four workflows pick this up from rust-toolchain.toml automatically. The release workflow is cargo-dist-generated and installs via rustup, so it inherits it too.

Why there are source changes

• Rust 1.97's clippy flags a redundant & passed to format-like macros, which 1.92's did not. Under CI's RUSTFLAGS=-Dwarnings these 9 warnings fail the Lints job, so the bump can't land without fixing them.
• All 8 source/test changes are the same one-character edit: format!("{}", &x) becomes format!("{}", x). Display and Debug forward transparently through references, so formatted output is byte-identical and no behavior changes.

Reviewing this

• 565183b is entirely mechanical, safe to skim.
• 6e25d06 is the one substantive line.
• The lint fixes land first so each commit passes clippy on its own (verified clean under both 1.90 and 1.97), meaning git bisect never lands on a red commit.

Contributor impact

• Local builds now need 1.97.1; rustup installs it automatically from rust-toolchain.toml.
• No rust-version/MSRV is declared in Cargo.toml, so no downstream compatibility constraint is affected.

Heads-up: unrelated flaky test

While running the suite locally, test_respect_gitignore_can_be_disabled failed once under full concurrent load, then passed in isolation. This looks like a pre-existing test-isolation bug rather than something introduced here:

• test_respects_global_gitignore mutates the developer's real global git config (git config --global core.excludesFile) and is marked #[serial].
• serial_test's #[serial] only serializes against other #[serial] tests, not against unmarked parallel ones, so test_respect_gitignore_can_be_disabled can run while excludesFile is mid-set/unset and pick up a bogus ignore path.
• This PR touches no gitignore or zeitwerk code, only format arguments.

If CI goes red on that test, this is the likely cause. Worth fixing separately.

Related: a failed local run can leave tests/fixtures/app_with_unnecessary_dependencies/packs/foo/package.yml modified, since test_auto_correct_unnecessary_dependencies rewrites it and skips cleanup when the suite aborts.

Follow-ups noted, deliberately not included

• parse_utils.rs:149-152 is if name.is_some() { name.unwrap_or_else(|| panic!(...)) }. The panic is unreachable given the guard and wants to be if let Some(..) = name. There is also a stale commented-out copy just above it that still contains the old &node, so it will drift further out of sync.
• ci.yml uses actions/checkout@v2 (deprecated Node runtime) and audit.yml uses the archived actions-rs/audit-check@v1.

🤖 Generated with Claude Code

[dduugg]

Approving — the bump itself is clean and low-risk. Two corrections to the description, both of which will misdirect the next reader if left as-is.

Verified

• All 8 format-arg edits are behavior-neutral. Every site is a format-like macro (println!/eprintln!/format!/panic!) — no write!, assert!, or structured tracing fields touched, no smart-pointer Display mismatch, and no site where the variable is later moved (format macros only borrow).
• No rust-version/MSRV in Cargo.toml, and none of the four workflows installs a pinned toolchain — all rely on the runner's rustup reading rust-toolchain.toml, so this file is the whole change surface.
• 1.97.1 installs and runs with both required components (clippy 0.1.97, rustfmt).
• parse_utils.rs:149-152 is exactly as described (unreachable unwrap_or_else(|| panic!(...)) behind an is_some() guard, plus a stale commented-out copy still carrying the old &node). Agreed it belongs in its own PR — it's a logic cleanup, not a lint fix.

---

1. The "Heads-up: unrelated flaky test" diagnosis is incorrect.

The section attributes test_respect_gitignore_can_be_disabled to #[serial] on test_respects_global_gitignore racing over core.excludesFile. That can't be the cause for this test:

• tests/fixtures/app_with_gitignore_disabled/packwerk.yml sets respect_gitignore: false, and src/packs/walk_directory.rs:146 gates build_gitignore_matcher behind exactly that flag — so this test never reads core.excludesFile at all, mid-set or otherwise.
• The global pattern written by that test is *.global_ignore, which could never mask ignored_folder/violating.rb.
• The observed failure is a cache-file creation error, not a missed violation, which independently rules out gitignore matching.

The real cause is the one #54 and #57 identify: common::teardown() globs tests/fixtures/*/tmp/cache/packwerk and deletes every fixture's cache, and gitignore_test.rs calls it from tests running on parallel threads in one binary. The precise window is src/packs/caching/per_file_cache.rs:59 (create_dir_all(parent)) vs :67 (File::create) — losing the parent between those two calls is why it surfaces as EINVAL rather than the ENOENT you'd expect.

Your general point about serial_test semantics (#[serial] only serializes against other #[serial] tests) is correct and worth keeping — it just isn't what breaks this test. Suggest replacing the section with a pointer to #57, which fixes it.

2. The "Follow-ups noted" section is stale.

actions/checkout@v2 and actions-rs/audit-check@v1 were both already fixed on main by #51 and #55 — main now pins actions/checkout@3d3c42e # v7.0.1 by SHA across ci.yml/audit.yml/zizmor.yml, and audit.yml has moved to taiki-e/install-action. They are still present on this branch, which forks from 0ccf146 — three commits before those landed — so the observation was accurate when written and will simply disappear on rebase. Worth dropping the section so it doesn't read as outstanding work.

[dduugg]

Non-blocking: 1.98.0 shipped 2026-08-18, so "the current stable release" in the description is now one behind. Pinning one release back is defensible — just noting the wording no longer matches if landing on current stable was the intent.

[dduugg]

Flagging this one site as the one worth actually reading rather than skimming, since it isn't the simple case the rest of the diff is.

name is bound by if let Some(name) = &self.defining_pack_name over an Option<String> field, so name is already &String — meaning the original format!(..., &name) was &&String, a double borrow, not the single &x -> x the description describes.

It is still correct to remove it: the blanket impl<T: Display + ?Sized> Display for &T makes Display transparent through any depth of references, so the formatted output is byte-identical. No change needed. Noting it only because a mechanical &-strip is exactly the kind of edit where a nested borrow can hide a real change, and this is the site a reviewer should verify by hand.