feat(dev): in-memory AST cache for perry dev rebuilds (V2.1)

[TheHypnoo]

Summary

V2.1 of the perry dev watch mode: an in-memory AST cache held across rebuilds in a single dev session. On each rebuild, files whose source bytes match the cached version skip SWC parsing and reuse the previous swc_ecma_ast::Module. Scope is strictly perry dev — perry compile and every other entry point pass None and behave byte-identically to v0.5.155.

This is the first of the two deliverables scoped in #131. The V2.2 follow-up (per-module .o reuse on disk, with cache keying over class-IDs / import prefixes / imported-function signatures / perry version / target / opt flags) is a separate PR tracked in that issue.

Smoke-tested on a two-module project with PERRY_DEV_VERBOSE=1:

Initial build:    parse cache: 0/2 hit (2 miss)
After edit:       parse cache: 1/2 hit (1 miss)   rebuilt in 502ms

What this changes

commands/compile.rs

• New pub struct ParseCache (path-keyed HashMap<PathBuf, ParseCacheEntry> storing { source: String, module: swc_ecma_ast::Module } plus hit/miss counters).
• New parse_cached(&mut ParseCache, &Path, &str, &str) -> Result<&Module> helper that does the full-source-bytes comparison and reparse-on-miss.
• collect_modules gains a trailing Option<&mut ParseCache> parameter, re-borrowed at its four recursive call sites via Option::as_deref_mut().
• New pub fn run_with_parse_cache(args, Option<&mut ParseCache>, ...). The existing pub fn run(...) delegates to it with None, so every callsite outside this PR is unchanged.

commands/dev.rs

• Owns one ParseCache::new() across the watch loop; reset_counters() before each rebuild; prints the per-rebuild hit/miss ratio when PERRY_DEV_VERBOSE=1.
• build_once threads the cache into run_with_parse_cache.

Design choices worth calling out

Content-addressed invalidation, not mtime. The cached entry stores the last seen source bytes and compares byte-for-byte on lookup. A formatter-on-save that changes trivia is a miss (correctly); a touch that only bumps mtime is a hit (correctly); git checkout to the same content is a hit. Byte comparison is O(n) but it beats parsing O(n) by a large factor, and we already have the bytes in hand from fs::read_to_string so there's no extra I/O.

No metadata-based heuristics. I considered mtime+size but that can get fooled by tools that rewrite files with the same mtime (rare but real), and metadata-only invalidation leaves the door open for subtle bugs. Full byte compare is simpler to reason about and costs microseconds.

Scope is dev-only. Every non-dev path still calls the unchanged pub fn run(...). This keeps the correctness risk bounded to the watch loop — where the worst-case failure mode is a confusing rebuild the user resolves by restarting perry dev.

No serialization, no disk. The cache lives in the perry dev process and dies with it. The on-disk equivalent is V2.2 in #131, which has its own ABI and cache-key concerns (class-ID coupling, import-prefix mangling, perry version gate) that aren't relevant here.

Test plan

• cargo test --workspace --exclude perry-ui-ios --exclude perry-ui-tvos --exclude perry-ui-watchos --exclude perry-ui-gtk4 --exclude perry-ui-android --exclude perry-ui-windows — all green.
• New unit tests in commands::compile::parse_cache_tests (8 tests, all pass):
  • cold lookup is a miss
  • identical source twice → hit
  • changed source → miss + entry replaced
  • revert to prior source is still a miss (documented behaviour — cache keeps only the latest version, not history)
  • distinct paths are independent
  • reset_counters clears counters but preserves entries
  • hit returns an equivalent AST to a fresh parse
  • parse errors propagate without poisoning subsequent lookups on the same path
• Existing commands::dev::tests (8 tests) still pass — V1 helpers untouched.
• End-to-end smoke test: two-module project, initial 0/2 hit, post-edit 1/2 hit with correct rebuilt output.

What's NOT in this PR

• Per-module .o cache on disk (V2.2 — issue V2 watch mode: incremental compilation cache — scoping (follow-up to #126) #131).
• Promotion to perry compile (explicitly out of scope for V2.1 per the issue's "Proposal" section).
• Per-session telemetry beyond the opt-in PERRY_DEV_VERBOSE=1 line.

Refs #131.

[proggeramlug]

This is looking great, will merge once the tests clear!

[TheHypnoo]

Empirical benchmark — V2.1 on its own is not a measurable improvement

Ran after opening the PR to sanity-check the real impact before merge. Synthetic project: 30 TypeScript modules, ~1700 LOC total, each rebuild editing a different module (→ 30/31 hit ratio under V2.1).

Configuration	Median rebuild (excluding the first, which is warmup)
V2.1 cache ON	~824 ms
Baseline (cache disabled = v0.5.155 behaviour)	~782 ms

V2.1 sits inside measurement noise, slightly below baseline on some runs. The reason is purely mechanical:

• SWC parses extremely fast (~1 ms per file, ~30 ms total on this sample).
• The full source byte comparison on the 30 hit paths costs roughly the same as the parse it avoids.
• Rebuild time is dominated by HIR lowering + codegen + link, none of which V2.1 touches.

I'm leaving the PR open anyway because:

1. The scaffolding (ParseCache, run_with_parse_cache, the threading through collect_modules) is exactly what V2.2 needs for the on-disk .o cache — it's reused verbatim, only the cached value changes (AST → object file).
2. The source byte comparison becomes the basis of V2.2's cache key (together with import_prefix_map + class_id_map + perry_version + target + opt_flags), so the work isn't thrown away.
3. No regression introduced: 8 new unit tests + the 8 existing dev tests still pass, and the full workspace is green.

The actual performance win lands with V2.2 — issue #131, plan A (per-module content-hashed .o cache). That's the ~60% of rebuild time (current codegen → 0 ms on hits), not a few milliseconds of parsing. This PR is the stepping stone.