GeezerVison

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

Fixes #1473
Fixes #1624

Summary

Hosted Poetry and PDM scans now parse each lock text once instead of five or six times. Output is byte-identical. On the bench fixtures (400 packages, 12 patched), callgrind shows:

Before this PR, toml_edit::Document::parse was 43–45% of all instructions in both scenarios. After it, the parse share is 22–27%.

Root cause (shared by both issues)

The Poetry and PDM hosted paths parse the same lock from several readers that knew nothing of each other. Callgrind callers of Document::parse on main:

Only two distinct texts exist: the lock as read, and as rewritten. rewrite_batch already parsed the rewritten text (to pair fragments) before VEX parsed it again.

Fix

• utils::lock_fragments::parse_lock is a read-only Document<String> parse behind a two-slot, bytes-keyed ParseMemo. It uses the same byte-equality contract as the vendor memos: a stale slot only ever costs a parse.
• The lock inventory, VEX extract_poetry/extract_pdm, LockParse::parsed (the PDM presence probe), rewrite_batch's original, and the Poetry stale-install check all read through it.
• rewrite_batch seeds the memo with the parse of its own output, so the post-write VEX read is free.
• The step-by-step fallback (LockParse::take) copies a shared parse when one exists. Otherwise it parses privately: its intermediate texts are never read again and must not evict the two that are.
• VEX toml_or_diag's diagnostic formatting is factored into toml_result_or_diag, so the shared parse produces the same lockfile_unparseable text.
• Under cfg(test) the memo is thread-local, so PARSES counts stay exact across parallel tests.

No wrapper (npm/, pypi/, gem/) changes: this is core-internal.

Tests (red → green)

Each test runs the hosted sequence: inventory, then VEX, then batch rewrite, then VEX on the written lock. It asserts the refs found and the rewritten text, and the PARSES count. To get the red run, the memo was bypassed (memo.invalidate() before every parse_lock): left: 5, right: 2 for both. The existing many_patches_render_the_lock_once tests (one render, two parses for Poetry) still pass.

Commands run locally:

• cargo fmt --all -- --check ✅
• cargo clippy --workspace --all-features -- -D warnings ✅
• cargo test --workspace --all-features --no-fail-fast: 7,522 CLI and 6,681 core tests pass. 10 fail, and all 10 are environmental in this sandbox (root user, no egress):
  • 9 chmod 0o555 write-failure tests. The 4 in core fail identically on unmodified main.
  • e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed needs patches-api.socket.dev.
• e2e_vex_build -- poetry:: --ignored with Poetry 2.4.3 ✅ (4/4)
• e2e_vex_build -- pdm:: --ignored with PDM 2.29.2 ✅ (2/2)
• in_process_redirect_poetry, in_process_redirect_pdm, hosted_superseding_pypi, e2e_pypi ✅
• Bench fixtures, base vs head binary: the --json output and every written project file (sha256) are identical.

/code-review high findings not fixed

The review found no correctness bugs. Fixed: step-path memo pollution and copies (562f0ab), the Poetry stale-install check's own parse, and an overclaiming doc comment. Not fixed:

• Retention. The memo holds up to two lock documents until the process exits. This is bounded, and it matches the vendor memos. Peak RSS during a scan is unchanged, because those documents were live during the rewrite anyway.
• Multi-lock workspaces. A project with several poetry.lock files, or with both poetry.lock and pdm.lock, can evict the root lock's slots. A miss costs exactly what main pays today.
• Key copy. The key duplicates the text bytes, which is inherent to ParseMemo's API. Keying on doc.raw() is a possible follow-up for every memo.
• Other sites. The upstream-redirect and vendor-backend parses of these locks are not on the hosted-scan path that the bench measures (callgrind shows no other lock parse). They are left for a follow-up.

Follow-ups (not in this PR)

What remains in rewrite_batch is per-dep linear scans: pdm_lock_fragments_in is called 24× (6% Ir) and plan_pdm_rewrite 12× (3%), each walking every [[package]]. Indexing packages by canonical name once per batch would remove most of that.

https://claude.ai/code/session_01M3qyYKFZLy31MhprAsdm24

Generated by Claude Code