Bump edition 2021 -> 2024. rust-version stays at 1.91, already well above
the 1.85 floor the edition needs; docs/guide/resources/troubleshooting.md
still claimed 1.70+, which is where a failed `cargo install --git` lands.
Four things the edition forces:
- std::env::{set_var,remove_var} are unsafe in 2024 with no safe std
replacement. Rather than wrap the test call sites in unsafe -- which the
crate denies and .semgrep.yml flags -- route them through temp-env, a
dev-only dependency whose closure API is safe and which restores the
previous value even when the body panics. The hand-rolled CLAUDE_DIR_LOCK
and PI_DIR_LOCK guards existed only to serialise those mutations and are
now redundant; CWD_LOCK and TEST_ENV_LOCK stay, they order more than the
env var itself.
- unsafe_op_in_unsafe_fn is on by default, so the libc calls in the proxy
signal handler and in stream.rs's relay handler need explicit unsafe
blocks, scoped to the libc calls themselves.
- `gen` is a reserved keyword, so the closure by that name in diff_cmd.rs
becomes make_lines.
- Tightened tail-expression temporary scopes let clippy prove the binding in
setup_test_env is inlinable, so let_and_return now fires there.
if_let_rescope changes when the scrutinee temporary drops in an if let/else.
The two sites in show_claude_config take cargo fix --edition's match rewrite,
which keeps the 2021 drop timing.
rustfmt.toml is kept rather than dropped: cargo fmt passes --edition from
Cargo.toml, but a bare rustfmt invocation has no crate context and falls
back to edition 2015, which cannot parse the let-chains the next commit
introduces. Pinning it there keeps format-on-save and pre-commit hooks in
agreement with CI.
clippy::collapsible_if is allowed crate-wide for now; the follow-up commit
adopts let-chains and removes the allow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every ecosystem mod.rs under src/cmds/ generated its module list with
automod::dir!(). rustfmt only follows literal `mod` items and cannot expand
macros, so `cargo fmt` never reached any of those files -- and neither did
CI's `cargo fmt --all -- --check` gate, which has been silently passing
over half the crate.
Demonstrated by appending `fn __probe( )->u8{let x=1;x}` to a file
under src/cmds/: with automod, `cargo fmt --all -- --check` reports no
diff; with an explicit `pub mod`, it reports the diff and `cargo fmt --all`
fixes it. The preceding commit had to invoke rustfmt directly for the same
reason; from here `cargo fmt` covers the crate on its own.
Listing modules by hand trades one failure mode for another, so build.rs
now guards the new one: automod compiled any stray .rs file, whereas an
explicit list silently drops a file whose `pub mod` line is forgotten --
never compiled, never linted, tests never run, and check-test-presence.sh
still reporting PASS because it only greps the file for #[cfg(test)]. The
build now fails with the missing declaration named.
Declaring the modules explicitly also exposed clippy::module_inception on
cmds::git::git, which clippy skips inside macro-generated code. git.rs is
renamed to git_cmd.rs, which resolves the lint and matches the convention
its siblings already follow -- diff_cmd, gh_cmd, glab_cmd, gt_cmd. Docs
that point at the module are updated; sample command output that merely
shows a "git.rs" path is left alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`Apache 2.0` is not a valid SPDX expression, so `cargo publish` rejects
the manifest and `brew audit` flags the generated formula. Use the
`Apache-2.0` identifier in both places.
The release workflow regenerates `Formula/rtk.rb` on every release, so
its heredoc was overwriting the already-correct value checked in at
`Formula/rtk.rb:10`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review response for upstream #3199 (KuSh round 2), plus preclear findings.
- Root-lane claims disarm on any fall-through line again (pre-d602a3b
behavior restored; tagged lanes keep the keyed-only rule). Fixes the
plain-mvn frame leak on the repo's own fixtures -- filter_compile output
is byte-identical to base ba7a9ce on mvn_test_fail_slice_raw.txt and
mvn_test_multifail_slice_raw.txt, pinned by fixture-backed tests. Full
base A/B: 56/56 outputs identical across all four entry points.
- Failures-summary tails are attributed per lane: dropped moves onto
SurefireLane, each lane's '+N more failures' tail flushes at that lane's
own aggregate (or at end-of-stream for truncated input), while the
reactor-wide entry budget stays shared. A module's tail can no longer be
collected under another module's header.
- is_lane_opener's [ERROR] arm narrowed to genuine compiler diagnostics
(FILE_COORD), so [tag] [ERROR] app logs no longer escape a buffered
block or get re-ordered ahead of it; they route by ownership rules.
- The [ERROR] arm sites only rewrite keep_continuation on the lane's own
keyed lines, matching every sibling arm/disarm site; interloper sweeps
now cover both [WARNING] and [ERROR] spellings on all three filters.
- insta removed (first dev-dependency, and .claude/rules/cli-testing.md
prescribes plain assert_eq! with include_str! fixtures): the four
snapshots are now expected-output fixtures under tests/fixtures/,
Cargo.lock drops insta/console/encode_unicode/similar.
- split_lane's no-trailing-space tagged blank pinned by tests.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mvnd builds multi-module reactors in parallel and prefixes per-module log
lines with `[module] `, interleaved line-by-line, while stack traces stay
raw. The Surefire matchers keyed on `[INFO]`/`[ERROR]` at column 0, so in a
parallel reactor a failing class lost its diagnostics: only the reactor
summary and the generic goal error survived.
- `split_lane` classifies on the prefix-stripped view and emits the original
line, so module identity survives in the output.
- One `SurefireLane` (block machine + keep-continuation + failures-summary
cap) per module, so a passing close from one module can no longer be
attributed to another module's open block. Unprefixed raw lines route to
the lane that most recently opened a block or failure trail.
- `filter_compile` classifies on the stripped view too.
Adds a real captured fixture (`mvnd clean test` on the new
multi-module-fail-skeleton, exit 1, interleaved reactor): the failing class,
its assertion message, the user stack frame, and the summary entry all
survive at 72.1% token savings.
Adds insta snapshot regression tests locking the full filtered output of all
four mvnd fixtures, per docs/contributing/CODING_PRACTICES.md.
Updates the jvm README: the parallel-reactor limit it documented is fixed;
only the `-q` daemon-chatter limit remains.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Addresses the inline review on #2717.
decode_process_output
- Decode a line at a time instead of reinterpreting the whole buffer at
the first bad byte. Valid UTF-8 lines keep their bytes; only lines that
fail UTF-8 validation go through the code page, so one stray byte no
longer mangles output that was almost entirely UTF-8. The line is the
unit because a byte run is not one: GB18030's four-byte sequences embed
bytes in the ASCII digit range, so any rule that ends a run below 0x80
splits them. \n cannot appear as a trail byte in any encoding handled
here, and a process does not switch encoding mid-line.
- A code page result is only accepted when it decodes cleanly, so a UTF-8
line with a corrupt byte falls back to lossy UTF-8 rather than mojibake.
- Replace the hand-written code page table with the codepage crate, as
suggested. That also fixes 54936, which was mapped to GBK and now
correctly resolves to gb18030.
- Add oem_cp for the legacy OEM/DOS pages (437, 850, 852, …) that plain
cmd.exe still defaults to in many locales. encoding_rs implements only
WHATWG encodings, so codepage alone returns None for them.
- Fall back to GetACP when GetConsoleOutputCP reports no console, which
is the piped case rtk normally runs in, and warn once instead of
falling back to lossy silently.
- Cache the code page lookup in a OnceLock.
- The mapping and the walk take the code page as a parameter, so they are
compiled and unit-tested on every platform rather than only Windows.
Call sites
- Route the remaining production sites through stream::exec_capture and
exec_capture_stdin rather than decoding at each one, so future callers
inherit decoding. git commit keeps inherited stdin via the _stdin
variant. Test-only sites go back to from_utf8_lossy: they assert on
rtk's own UTF-8 output, where a console code page has no meaning.
- Decode the streamed path (read_lines_lossy) too — the OEM/ANSI lines
its comment describes were still going straight to U+FFFD.
- curl keeps its body on from_utf8_lossy: a response body is a network
payload whose encoding comes from the HTTP charset, not the local
console, and non-UTF-8 bodies already take the binary passthrough for
#1087. Only curl's own stderr is code page decoded.
git commit summary parsing
- parse_commit_output sliced from byte 1, which panics when the first
line starts with a multi-byte character — git prints hook output before
its summary, and a lossily decoded line starts with a multi-byte
U+FFFD. Locate the bracket pair with find instead, so both indices are
character boundaries.
Verified: unit tests for the walk, GBK, gb18030, CP437/850, mixed lines,
truncated input and every byte value; a test pinning that output without
a code page stays byte-identical to from_utf8_lossy; and the Windows-only
lookup cross-compiled for x86_64-pc-windows-msvc.
Replace hand-written FFI extern block with windows-sys crate binding
for GetConsoleOutputCP to satisfy semgrep unsafe-block rule. Rewrite
test_decode_process_output_gbk to test encoding logic directly via
codepage_to_encoding(936) instead of relying on the CI runner's
actual console code page (which is not GBK on GitHub Actions).
On Windows with non-UTF-8 console code pages (e.g., GBK for Chinese
locale), child process output is mis-decoded by String::from_utf8_lossy,
producing mojibake. Add decode_process_output() that detects the console
output code page via GetConsoleOutputCP() and decodes with encoding_rs.
Replaces from_utf8_lossy in the core capture paths (exec_capture,
exec_capture_stdin, TOML filter path, proxy streaming path). Module-
specific call sites left for follow-up.
Fixes#2452
rtk uses `str::floor_char_boundary()` (src/cmds/system/pipe_cmd.rs:140)
which was stabilized in Rust 1.91.0. Without `rust-version` in
Cargo.toml, packagers on older toolchains hit a confusing
`use of unstable library feature` error from rustc.
With this declaration, cargo gives the expected friendly diagnostic
up-front:
error: rustc 1.88.0 is not supported by the following packages:
rtk@0.34.3 requires rustc 1.91
Verified locally by switching toolchains:
- cargo +1.88 check → fails with the new clear MSRV error (intended)
- cargo +1.93 fmt/clippy/test → 1909 passed, zero warnings
Fixes#1402
Keep develop's [Unreleased] section on top, followed by master's
released versions (0.34.3, 0.34.2).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Drop-based ChildGuard doesn't run on signals with panic=abort (release
profile). Register a signal handler that stores the child PID in an
AtomicU32 and kills it on SIGINT/SIGTERM, then re-raises the signal
with default handler for correct exit status propagation.
Fixes orphan processes when rtk proxy is killed by Claude Code, process
managers, or manual kill — the root cause behind issue #897.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nicolas Le Cam