Repository navigation
Conversation
A generic function is analyzed once per instantiation, but its basic block types were stored under its LocalDefId alone. Analyzing one instantiation from inside another (e.g. g::<i32> calling g::<i64>) overwrote the outer instantiation's blocks, so the outer analysis continued with the inner one's block types and predicate variables. This either panicked with "precondition is already registered for basic block" or silently verified the outer instantiation against the inner one's behaviour. Fixes #328 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q3Dt425cRNNW8aSShzGyDA
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q3Dt425cRNNW8aSShzGyDA
There was a problem hiding this comment.
🟢 Approval recommended
The implementation consistently isolates per-instantiation block state and includes a focused bidirectional regression test.
0 open findings
What changed in this PR
Keys basic-block analysis state by both definition and generic arguments, preventing nested generic instantiations from corrupting each other.
Changes:
- Introduces
LocalDefInstantiationand threads it through analysis. - Keys basic-block types by full instantiation.
- Adds pass/fail regression tests for nested polymorphic calls.
| File | Description |
|---|---|
src/analyze.rs |
Adds instantiation-aware basic-block storage APIs. |
src/analyze/local_def.rs |
Supplies generic instantiation keys during analysis. |
src/analyze/basic_block.rs |
Uses instantiation keys for block lookups and registration. |
tests/ui/pass/fn_poly_nested_instantiation.rs |
Verifies the correct nested-instantiation result. |
tests/ui/fail/fn_poly_nested_instantiation.rs |
Rejects the incorrect result. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Fixes #328.
A generic function is analyzed once per instantiation, but its basic-block types were stored under
LocalDefIdalone. When one instantiation was analyzed from inside another (for example,g::<i32>'s body callsg::<i64>), the nested run overwrote the outer run's block entries. The outer analysis then carried on with the inner instantiation's block types and predicate variables. Depending on the CFG, this either panicked withprecondition is already registered for basic blockor, with no error, verified the outer instantiation against the inner one's behaviour. In the second case, a panicking program verified assafe.Changes
LocalDefInstantiation, which pairs aLocalDefIdwith theGenericArgsRefit is instantiated with.Analyzer::basic_blocksis now keyed byLocalDefInstantiation. The register and lookup methods take one instead of a bareLocalDefId.basic_block::Analyzerholds theLocalDefInstantiationit analyzes, whichlocal_def::Analyzerbuilds from itslocal_def_idandgeneric_args.fn_poly_nested_instantiation.rspass/fail UI test pair, built from the issue's reproducer. Onmainboth files get the wrong verdict (pass→Unsat,fail→safe).Validation
cargo test: all 396 UI tests pass, run with the pinned Z3 5.0.0 and PCSat wrapper.cargo clippy -- -D warningsandcargo fmt --all -- --checkare clean.W<W<i32>>delegating trait impl) now verifies, and its broken variant is rejected.🤖 Generated with Claude Code
https://claude.ai/code/session_01Q3Dt425cRNNW8aSShzGyDA