GeezerVison

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

Fixes #1509

Summary

A gem declared inside the user's own source block keeps its ! pin
through hosted rollback / remove (#1056). That only worked for the
one-line source "…" do spelling. Two other valid spellings lost the
!, and Bundler 4.0.19+ then refused every frozen install of the
restored pair (exit 16):

• a source( opener whose arguments span lines before ) do
• a source("…") { … } brace block, which also came back with the gem
  at column 0 after an extra blank line

Root cause

block_stack in crates/socket-patch-core/src/patch/redirect/upstream/gem.rs
is the Gemfile scanner behind both the ! check (in_source_block) and the
restored declaration's indent (declaration_prefix). It ended a statement
at the end of any line not ending in an operator, so an unclosed ( didn't
keep the source statement open until its do. It also never opened a
frame for { … }.

Fix

• A statement stays open while a (, [ or hash { is unclosed, and
  remembers that it began with source until its block opens. The do
  at depth 0 is the source's block.
• { opens a frame that } closes. A { in expression position is a
  hash, which counts toward depth and has no frame. Only the brace block
  directly after the source(…) argument list is the source's, so in
  source ENV.fetch("S") { … } do the do is still the source block. A
  stray } never closes a do block.
• Character literals (?(, ?}) are masked so they aren't read as
  brackets.
• Frame records the line its opener sits on, so a gem restored first
  in a multi-line source( block gets no blank line after ) do.
• Only the end of an unfinished line is carried forward, since that is
  all starts_expression reads. This keeps a long open bracket linear.

The second and third commits apply the /code-review high findings: the brace
binding, hash braces in arguments, a ; inside the argument list, stray
} and ?( literals, the multi-line opener's blank line, quadratic
carry, and a duplicate ident helper. The third commit fixes a review finding: a leading if inside an open bracket or -> { lambda now opens its own frame, and an open bracket only carries a source statement.

Tests (red → green)

• Red, before the fix: both unit tests failed (assertion failed: at("source(\n \"https://x\"\n) do …"), and the restore lost the !: rails (= 7.0.0) vs rails (= 7.0.0)!). The e2e test failed on Bundler 4.0.22 with rollback: the lock comes back byte for byte, ! included and DEPENDENCIES\n vuln-gem (= 1.0.0) without the !.
• Green, after the fix:
  • cargo test -p socket-patch-core --all-features --lib -- gem: 357 passed
  • cargo test -p socket-patch-cli --all-features --test e2e_redirect_gem_build -- --ignored (Ruby 3.3.6, Bundler 4.0.22): 30 passed
  • cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings: clean
  • cargo test --workspace --all-features: couldn't finish locally: the session's disk allowance ran out linking every integration-test binary, so CI runs it. cargo test -p socket-patch-core --all-features --lib (all 6472) passes except 4 chmod-based permission tests (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…). Those can't fail as expected under uid 0 in this sandbox, and this diff doesn't touch them.

No wrapper changes: npm/, pypi/ and gem/ only dispatch to the binary.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hsu76uJiHbbPSV1iSeEukP

Generated by Claude Code