GeezerVison

Review follow-up 464896d: closes the remaining interpolated-heredoc case in the shared Gemfile tail guard. Hosted and vendored modes leave unsupported declarations unchanged; native CLI tests also require zero redirects and VEX statements and a successful Bundler install. Preserves the author’s colon-modifier and ordinary-heredoc fixes. Validated with 267 core tests and four native tests covering five fixtures (Ruby 3.4.10 / Bundler 4.0.15); targeted Clippy and changed-hunk formatting checks pass. Ready to merge as-is from this review. 482 successful checks, 6 skipped, and all twelve workflows successful. Bugbot is clear on this commit; no unresolved review threads or new actionable findings.

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

Fixes #340

Summary

Hosted scan no longer rewrites a Gemfile gem declaration that continues on the next line or carries a modifier. Before this fix:

• gem "vuln-gem", ↵ require: false became a source block followed by an orphaned require: false, so every later bundle install failed to parse the Gemfile, while scan exited 0 and VEX attested the patch;
• gem "vuln-gem" if ENV["WITH_VULN"] != "0" became an unconditional declaration, so the condition was silently dropped.

Both shapes now skip the redirect with the existing redirect_gem_unrecognized_declaration warning (its detail now names the reason) and leave the Gemfile and lock byte-identical.

Root cause

The hosted rewriter (patch/redirect/mod.rs, gem_line_re → gem_line_trailing_options) replaces the declaration's single line with a source … do … end block, but it had no check that the line holds the whole declaration. Vendored mode had one (vendor::gem::rest_blocks_edit), but it used substring checks (ends_with(','), contains(" if ")) that missed several shapes.

Fix

• New shared gem_line_tail_blocks_edit (next to gem_line_trailing_options) scans the tail outside string literals and comments. It refuses:
  • an unterminated string, an unclosed (/[/{, or a heredoc (<<);
  • a tail that doesn't end in a value character (dangling ,, =>, key:, \);
  • a non-,-led tail;
  • a standalone if/unless/while/until/rescue/and/or/do keyword. Symbols (:unless), string contents, and hash keys (if: only where an argument can start, after ,, ( or {, and never if::) don't count. So "1.0.0" if::FEATURE and "1.0.0" if:flag == … are refused as modifiers.
• Hosted mode calls it after the existing source-option check, so the redirect_gem_source_option and own-vendored-wiring messages are unchanged.
• Vendored rest_blocks_edit delegates its structural checks to the same helper and keeps its source-token refusal. Behaviour there is stricter only on shapes that were already broken: a [ continuation, => continuation, tab-separated unless, rescue modifier, label-style modifiers, heredocs.
• The npm/pypi/gem wrappers only dispatch to the binary, so they need no change.

Test evidence

I got the red results by checking out main's crates/socket-patch-core/src with only the new tests applied. For 84a43d4, the if::FEATURE case was confirmed red against 369daa5's guard.

Local runs:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast (at 369daa5): 9726 passed, 12 failed. All 12 are permission-denial or write-failure simulations (covgap_commands_vendor *_state_write_failure_*, repair_*unremovable*, *write_failure*, relax_loop_must_not_traverse_symlinked_root, …). They can't fail as intended in this sandbox, which runs as root (uid 0), and none of them touch gem code. CI runs as non-root, and all of these pass there. At 84a43d4, the core lib tests (same 4 root-only failures) and 91 CLI gem tests were re-run.
• cargo fmt: main itself isn't rustfmt-clean (about 500 diffs) and CI doesn't gate on it, so this PR formats only its own hunks.

🤖 Generated with Claude Code

https://claude.ai/code/session_015ZK1CuReoar7pKs2eZwepT