GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #826

Summary

A Gemfile line holding two ;-joined declarations (gem "colorize", "0.8.1"; gem "rainbow", "3.1.1") lost its second gem when socket-patch redirected (hosted) or vendored the first one. Hosted scan exited 0, and the next frozen bundle install failed. Such lines are now refused with the existing redirect_gem_unrecognized_declaration warning (hosted) or a not editable refusal (vendored), and nothing is written.

The PR also fixes the opposite regression from #637. A complete declaration ending in a bare ; (gem "colorize", "0.8.1";, optionally followed by # comment) was refused as "continues on the next line". It is rewritten again, and the ; is dropped from the kept options.

Root cause

Both Gemfile rewriters replace the declaration's whole physical line, and both gate that on the shared gem_line_tail_blocks_edit (crates/socket-patch-core/src/patch/redirect/mod.rs; vendored calls it through rest_blocks_edit). The gate had no notion of a top-level ; statement terminator:

• When something followed the ;, it looked like ordinary code, so the gate accepted the tail and the line rewrite deleted the second statement.
• When nothing followed it, the last-character check read ; as a dangling continuation.

Fix

• gem_line_tail_blocks_edit: a ; outside strings and brackets ends the statement. If anything other than more ;s, whitespace or a # comment follows, it refuses with "another statement follows the declaration on its line". Otherwise scanning stops there, so the end-of-code checks see the declaration without its terminator.
• formats::gem::gemfile (the shared option reader both rewriters use since Fix gem source-option guard missing git sources (#652) #731): trailing_options and source_option first drop that terminator via the new without_statement_end, keeping a trailing comment and any ; inside strings or the comment. Without that, "1.0"; would read as a positional argument and be kept, and a bare ; # c tail would fail closed as an unreadable, source-selecting option.

There is one fix point for both modes. The npm/pypi/gem wrappers have no Gemfile logic and need no change.

Ported from #878 (commit 5b9953d): main is red on utils::digest::tests::production_digests_go_through_the_helpers, because #646 added inline digest calls that #865's guard rejects. This port routes them through utils::digest and becomes a no-op once #878 lands.

Test evidence

Commands run locally on the merge with main 9c43dfc (Linux, Ruby 3.3.6, Bundler 4.0.17, toolchain 1.93.1):

• cargo test -p socket-patch-core --all-features --lib: 5251 passed. The 4 failures (relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files) all rely on permission bits, which have no effect when the container runs as root.
• SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1 cargo test -p socket-patch-cli --all-features --test e2e_redirect_gem_build --test e2e_vendor_gem_build -- --ignored: 18 + 8 passed.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo fmt --all -- --check: clean for every hunk in this PR. main itself has pre-existing rustfmt diffs elsewhere, which CI doesn't check, and this PR leaves them alone.

CI on 5b9953d: all 12 workflows are green. The macOS/ubuntu/Windows jobs that were cancelled without ever getting a runner, and the one Bun Windows workspace-nested vendored cell, passed on a single re-run. Bugbot is clean at 5b9953d. On 2026-10-06 one Bun native (macos-latest, 0.8.1) job had sat queued with no runner since the previous re-run. A second re-run of that workflow passed, and every check on 5b9953d is now green.

Follow-ups

None for #826. Parenthesized calls ending in ); (gem("x", "1");) are still refused. That fails closed with a warning, and nobody has reported it.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ZTJ2BGpGJYPCaQvncWGPm