feat(opy): complete bounded canonical lowering - #150
Conversation
Teakowa
left a comment
There was a problem hiding this comment.
Major — crates/opy-rs/src/compiler/mod.rs:3364
The new literal-dict fast path only handles a matching key. A valid literal miss (for example {"a": 1}["b"]) falls through to generic Expr::Dict lowering and is rejected. The pinned OverPy implementation instead lowers dict access through key/value arrays; for an all-literal miss .index folds to -1, then __valueInArray__ folds the negative index to null. Handle the missing-key case and add oracle-backed coverage before claiming compilation/opy-literal-dict-lookup end-to-end supported.
Major — compatibility/support-matrix.json / Fixes #145
#145 explicitly subsumed #60, and #60 was closed as “superseded by #145”, but this PR still leaves deeper indexed writes “tracked by #60” while closing #145. The current compiler expectations also retain synthetic/issue-31-positive as a known-gap owned by opy-rs#145. Merging this as Fixes #145 therefore leaves declared lowering gaps without a live follow-up owner and does not satisfy #145’s category-level completion contract. Either complete/reclassify those #145-owned boundaries here, or keep #145 open (within its two-PR budget) and give the remaining gap an active owner.
Summary
Verification
cargo fmt --all -- --checkpython3 -m unittest discover -s compatibility/testscargo clippy --workspace --all-targets --all-features -- -D warningscargo test --workspace --all-targets --all-featuresScope note
The remaining chase fixture semantic gap is tracked by
opy-rs#144; the broad issue-28 oracle snapshot remains a declared #88 corpus boundary because the released Workshop parser cannot currently reparse its uppercase hexadecimal spelling. No unowned OPY lowering gap is introduced by this PR.Fixes #145