Fix VEX gemspec reading commented-out name/version (#1573)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1573

Summary

vex (and scan / apply / vendor --vex without --vex-product) names a gem library's top-level product from its root *.gemspec. A commented-out assignment used to win over the live one:

• # spec.version = "0.0.1" above spec.version = Acme::VERSION gave pkg:gem/acme@0.0.1. It now gives pkg:gem/acme, because a computed version is dropped as documented.
• # spec.name = "acme-legacy" above spec.name = "acme" gave pkg:gem/acme-legacy. It now gives pkg:gem/acme.

Root cause

parse_gemspec (crates/socket-patch-core/src/vex/product.rs) took the first line whose left side of = ended in .name / .version and whose right side was a quoted literal. It never skipped Ruby comments. Because it also skipped computed right-hand sides and kept searching, the first literal anywhere in the file won, even when Ruby's effective value was a later computed one.

Fix

• parse_gemspec now reads the file through formats::gem::manifest::for_each_code_line, the Ruby line lexer the Gemfile readers already use (made pub(crate)). That lexer skips # comments outside strings, =begin / =end blocks, heredoc bodies and everything after __END__.
• The last live assignment wins, as in Ruby (Gem::Specification.load). If it is computed, the version is dropped and the name falls back to the file stem.
• When the file names the Gem::Specification.new do |spec| block parameter, only assignments to that receiver count, so a helper's ext.name = … can't rename the product.
• Each line's code is split into statements on ; (outside strings), after any block opener, so a one-line Gem::Specification.new { |s| s.name = "a"; s.version = "1" } is read. This came from Bugbot's finding on c6b44b2.
• =~ and == comparisons are still not taken for assignments.

No wrapper changes are needed: npm/, pypi/ and gem/ don't read gemspecs.

/code-review high

I ran it on the first revision. Its main point was that the PR duplicated the crate's existing Ruby lexer, so the second commit reuses it. That also fixes the findings about __END__, lower-case and backtick heredocs, and the per-line quote handling. I also took the receiver finding (match the spec's block parameter), dropped the redundant \r strip, and dropped the Vec::remove(0) allocation note along with the duplicated code. Not changed: a bare <<ID closing on an indented ID line, and 1<<SHIFT read as a heredoc opener. Both are limitations of the shared lexer that every Gemfile reader already has, and neither shape is plausible in a gemspec. Changing them belongs in a lexer fix, not this PR.

Test evidence

• New vex::product::tests::detect_gemspec_ignores_commented_assignments covers both shapes from VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 and the variants the issue lists: trailing # comments, =begin/=end, heredocs (bare and quoted), << inside a string, a __END__ DATA section, another receiver's .name / .version, assignments on the block-opener line and after ;, last-assignment-wins, a trailing comment after a live literal, and the stem fallback.
  • Red on main: assertion failed: commented literal version above a computed one; left: Some("pkg:gem/acme@0.0.1") right: Some("pkg:gem/acme")
  • Green with the fix: cargo test -p socket-patch-core --all-features --lib vex::product gives 146 passed (194 with formats::gem).
• cargo fmt --all -- --check: clean.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test --workspace --all-features --no-fail-fast: 14,575 passed, 10 failed. All 10 come from the sandbox and none touch this change. Nine are permission-based failure-injection tests (chmod-made unwritable or unremovable paths) that can't fail when tests run as root. The tenth, e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, needs patches-api.socket.dev, which this sandbox can't reach (tunnel error). CI runs these normally.

Per-issue checklist

• VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 commented version: case "commented literal version above a computed one"
• VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 commented name: case "commented name above the live one"
• VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 =begin/=end and heredocs: cases "=begin / =end block", "heredoc body", "quoted heredoc identifier"

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 9de072d. Configure here.}