Reviewing files that changed from the base of the PR and between 711b1a6 and f6415fc.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/frame.rs (4 hunks)
• vm/src/types/slot.rs (1 hunks)

• GitHub Check: Check the WASM package and demo
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run tests under miri
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Ensure compilation on various targets

extra_tests/snippets/syntax_match.py (2)

67-71: Good assertions for two-key mapping; keep the negative branch explicit.

Explicit assertions on x and y make failures easier to diagnose, and the catch-all case ensures the test fails loudly if the pattern doesn’t match.

---

80-88: Empty-rest case looks good.

Verifies that rest captures an empty dict when there are no extra keys. Solid.

compiler/codegen/src/compile.rs (9)

3289-3303: Correct index computation for post-star sequence elements.

Using len(subject) - (size - i) by loading GetLen and then (patterns.len() - i) is the right fix for indices after a starred element.

---

3521-3527: Good early validation of key/pattern length mismatch.

Clear error message; prevents subtle stack discipline bugs later in MATCH_KEYS handling.

---

3540-3546: Efficient fast-path for empty mapping pattern without rest.

Early-return and pop the subject in the {} case is correct and avoids extra work.

---

3548-3562: Length pre-check aligns with CPython semantics.

len(subject) >= size check before key lookup is consistent with expected behavior.

---

3564-3569: Overflow guard makes sense.

The i32::MAX + 1 bound matches CPython’s intent for “too many sub-patterns in mapping pattern.”

---

3611-3629: Potential stray boolean on stack after MATCH_KEYS None-check.

The sequence:

• CopyItem(1) # duplicate values_or_none
• LoadConst(None)
• TestOperation(IsNot)
• jump_to_fail_pop(... PopJumpIfFalse)

If JumpIfFalse doesn’t pop the tested value (it often does not, whereas JumpIfFalseOrPop does), the boolean result may remain on the stack, skewing on_top accounting. If your VM’s JumpIfFalse pops, ignore this; otherwise, add a Pop after the check passes.

Minimal patch:

         self.emit_load_const(ConstantData::None);
         emit!(
             self,
             Instruction::TestOperation {
                 op: bytecode::TestOperator::IsNot
             }
         );
-        // Stack: [subject, keys_tuple, values_tuple, bool]
-        self.jump_to_fail_pop(pc, JumpOp::PopJumpIfFalse)?;
+        // Stack: [subject, keys_tuple, values_tuple, bool]
+        self.jump_to_fail_pop(pc, JumpOp::PopJumpIfFalse)?;
+        // On success, drop the bool (keep original values_tuple)
+        emit!(self, Instruction::Pop);

Please verify the VM’s JumpIfFalse behavior and adjust accordingly.

---

3631-3635: Double-check on_top adjustment after unpacking values.

You do:

• pc.on_top += size
• pc.on_top -= 1

Sequence patterns do not subtract 1 right after unpack; they only decrement per subpattern. That extra -1 can throw off fail_pop accounting. If tests reveal mismatched pops on failure paths, consider dropping the -1:

-        pc.on_top += size; // Unpacked size values, tuple replaced by values
-        pc.on_top -= 1;
+        pc.on_top += size; // Unpacked 'size' values, tuple replaced by values

Flagging as a verification item due to subtlety.

---

3921-3924: Singleton patterns now use identity (is) instead of equality.

This aligns with CPython 3.10+ semantics for None/True/False.

---

3996-4007: Guards are compiled and short-circuited properly.

JumpIfFalseOrPop to the failure target matches CPython behavior; great to see guards wired in for both normal cases and the default case below.

vm/src/builtins/bytearray.rs (1)

173-187: Add _MATCH_SELF flag for bytearray is consistent with class-pattern semantics.

This makes patterns like case bytearray(x) bind x to the subject itself, per the new MATCH_SELF behavior. Looks good.

Please ensure the flag is consistently applied across all intended builtins (bool, bytes, dict, float, int, list, set, str, tuple) and that vm/src/frame.rs uses it for MatchClass extraction. I can provide a quick repo scan if helpful.

vm/src/builtins/bytes.rs (1)

135-149: _MATCH_SELF on bytes aligns with case bytes(x) matching “self”.

Matches the intended “str(x) fix” family of changes. No further issues spotted here.

vm/src/builtins/dict.rs (1)

179-181: _MATCH_SELF on dict is in line with new pattern-matching rules.

Enables case dict(x) to bind the subject as x. The rest of the file remains unaffected.

vm/src/builtins/set.rs (2)

523-533: Add _MATCH_SELF to set: correct for class-pattern semantics

The new flags(BASETYPE, _MATCH_SELF) on PySet is aligned with CPython’s MATCH_SELF behavior, enabling patterns like case set(x) to bind the subject itself. This doesn’t interfere with sequence/mapping detection (set is neither), so risk is low. LGTM.

---

948-951: Add _MATCH_SELF to frozenset: consistent and desirable

Mirrors the PySet change and enables case frozenset(x) to bind the subject. Matches CPython semantics; no concerns.

vm/src/builtins/list.rs (1)

102-114: List now participates in MATCH_SELF patterns

Including _MATCH_SELF (while retaining SEQUENCE) correctly enables case list(x) to bind the subject itself, without affecting existing sequence-pattern matching. Looks good.

vm/src/builtins/float.rs (1)

203-207: Float marked with _MATCH_SELF: enables case float(x) binding

This is consistent with CPython and the rest of this PR. No functional risks identified.

vm/src/builtins/int.rs (1)

319-323: pyclass flags for PyInt are correctly applied
Verified that this file contains three #[pyclass] attributes, with only the impl PyInt block carrying the intended flags:

• vm/src/builtins/int.rs:27 – #[pyclass(module = false, name = "int")] on the pub struct PyInt (intentionally flag-less)
• vm/src/builtins/int.rs:321–323 – #[pyclass(flags(BASETYPE, _MATCH_SELF), …)] on impl PyInt (correct, matches CPython behavior)
• vm/src/builtins/int.rs:704 – #[pyclass] on impl PyRef<PyInt> (intentionally flag-less)

No other flags-bearing pyclass declarations remain. The summary should note a single flags-bearing update.

vm/src/types/slot.rs (1)

132-136: Introduce PyTypeFlags::_MATCH_SELF: matches CPython’s intent

Defining _MATCH_SELF (1 << 22) with a clear doc comment is the right foundation for built-ins that pattern-match the subject itself. Bit placement doesn’t collide with existing flags. LGTM. As a follow-up, ensure test coverage includes positional class patterns for these built-ins (positive and negative cases), e.g., str(x), int(x), list(x), set(x), frozenset(x), and that user-defined classes without match_args don’t accept 1 positional arg.

Example tests to consider adding (Python):

def test_match_self_builtins():
    for obj in [42, 3.14, "hi", b"b", bytearray(b"a"), [1], (1,), {1:2}, {1}, frozenset({1})]:
        match obj:
            case int(x) | float(x) | str(x) | bytes(x) | bytearray(x) | list(x) | tuple(x) | dict(x) | set(x) | frozenset(x):
                assert x is obj
            case _:
                assert False, f"no match-self for {type(obj)}"

def test_no_match_self_user_class():
    class C: pass
    c = C()
    matched = False
    try:
        match c:
            case C(_):  # should be invalid without __match_args__ or MATCH_SELF
                matched = True
    except TypeError:
        pass
    else:
        assert not matched

vm/src/builtins/tuple.rs (1)

246-258: Adding _MATCH_SELF to tuple is correct and aligns with class-pattern semantics

Flagging tuple with _MATCH_SELF enables patterns like case tuple(x) to bind the subject itself when there are no __match_args__. This matches the intent of the PR and mirrors how other builtins are handled. No runtime behavior changes here, just metadata; looks good.

To double-check coverage, consider adding/expanding a snippet like:

• match (1, 2): case tuple(x): assert x == (1, 2)
• Ensure subclass behavior still follows spec (i.e., only exact tuple types should provide MATCH_SELF unless the subclass opts in).

vm/src/builtins/str.rs (1)

523-536: Enable MATCH_SELF for str to fix str(x) matching

Adding flags(BASETYPE, _MATCH_SELF) on PyStr is the right hook for case str(x) to capture the subject. The change is local to type metadata and should work in tandem with the Frame’s MatchClass extraction.

Please ensure tests cover:

• match "hi": case str(x): assert x == "hi"
• That multi-arg str(a, b) patterns fail as non-match, not with TypeError.

vm/src/builtins/bool.rs (1)

112-113: Add _MATCH_SELF to bool

Consistent with other builtins. Keeping bool non-BASETYPE is correct (bool isn’t a valid base), so only _MATCH_SELF here is appropriate.

Consider adding a quick check:

• match True: case bool(x): assert x is True

vm/src/frame.rs (4)

1297-1305: MatchMapping: switch to PyTypeFlags::MAPPING — good move

Using PyTypeFlags::MAPPING for the fast-path mapping check matches the new flag-based approach. This also keeps behavior consistent with how CPython’s VM guards mapping-ness in matching.

Please confirm consistency with MatchKeys: given the flag check here, MatchKeys should assume a mapping and only treat KeyError as “no match” (see separate note below).

---

1308-1316: MatchSequence: flag-based sequence detection is fine

Aligns with the mapping change and simplifies the check. No issues spotted.

---

1359-1464: The above scripts will:

• Dump the MatchClass handling code so we can confirm it currently swallows every Err(_) and never distinguishes AttributeError from other exceptions.
• Show where else fast_isinstance is used in the VM to verify we can safely pattern-match on e.fast_isinstance(vm.ctx.exceptions.attribute_error).

Once we have those results, we can confirm whether the suggested diffs are applicable and correctly aligned with the rest of the codebase.

---

1297-1317: All _MATCH_SELF flags and MatchClass handling verified

• Confirmed that every built-in type (bool, bytes, bytearray, dict, float, int, list, set, str, tuple) in vm/src/builtins/*.rs is declared with flags(..., _MATCH_SELF)
• Verified that PyTypeFlags in vm/src/types/slot.rs includes const _MATCH_SELF = 1 << 22;
• Spot-checked vm/src/frame.rs and found a complete Instruction::MatchClass arm (lines 1359–1464) with both the MATCH_SELF fallback and appropriate error handling

All checks pass – no further changes needed.

Reviewing files that changed from the base of the PR and between f6415fc and 0bb06ab.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/frame.rs (4 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/bool.rs
• vm/src/builtins/bytes.rs
• vm/src/builtins/dict.rs
• vm/src/builtins/bytearray.rs
• vm/src/builtins/set.rs
• vm/src/builtins/str.rs
• vm/src/builtins/tuple.rs
• vm/src/types/slot.rs
• vm/src/builtins/int.rs
• vm/src/builtins/list.rs
• vm/src/builtins/float.rs

• GitHub Check: Check the WASM package and demo
• GitHub Check: Run tests under miri
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Ensure compilation on various targets
• GitHub Check: Run rust tests (windows-latest)

extra_tests/snippets/syntax_match.py (6)

65-71: Good strengthening of exact bindings in two-key mapping pattern.

Asserting concrete bound values for x and y plus an explicit failure path is correct and guards regressions in key lookup/binding.

---

72-79: Nice addition: rest-capture semantics validated.

This verifies that the unmatched keys are captured into rest as a dict, which aligns with PEP 634. Good negative branch, too.

---

80-88: Covers empty-rest case well.

Confirms rest is {} when no extra keys remain; this is an important edge case for mapping patterns with rest.

---

90-96: Multi-key rest coverage looks solid.

Validates that rest accumulates the correct remainder without disturbing bound x and y.

---

99-106: Three-key + rest case completes the grid.

This extends coverage to larger patterns and verifies rest size/contents after multiple exact key binds.

---

108-126: Wildcard fallback tests are helpful and realistic.

These mirror real-world patterns (e.g., wheelinfo). The success and failure paths are clear.

vm/src/frame.rs (3)

1452-1459: Overall MatchClass tuple assembly and non-instance path look correct.

On success, the extracted positional+keyword values are returned as a tuple; on non-instance, pushing None matches CPython’s behavior.

---

1297-1317: Minor consistency note: MatchMapping/MatchSequence use flags, while MatchKeys checks PyMapping protocol.

This is acceptable if the compiler guarantees MatchKeys only runs after a successful MatchMapping flag check. If not, consider aligning MatchKeys’ mapping check to flags for consistency.

Would you like me to align MatchKeys to use flags and fall back to protocol methods only when needed?

---

1300-1305: Audit mapping flags for all mapping types

Switching to PyTypeFlags::MAPPING in the pattern matcher is correct, but I only see it referenced in frame.rs and in the inherit_patma_flags helper (vm/src/builtins/type.rs) (github.com). You need to confirm that every mapping-like type explicitly sets this flag during its registration. In particular, please verify and update as needed:

• vm/src/builtins/dict.rs — ensure the PyTypeSlots.flags for PyDict includes PyTypeFlags::MAPPING.
• vm/src/builtins/mappingproxy.rs — likewise, it must carry the mapping flag.
• The implementations of collections.UserDict and OrderedDict (wherever they’re defined) — these custom types must also set PyTypeFlags::MAPPING.

If any of these are missing the mapping bit, they won’t be recognized as mappings by the VM’s pattern matcher.

compiler/codegen/src/compile.rs (7)

294-294: Fix incorrect index calculation for GetLen in sub-patterns

The change from (patterns.len() - 1) to (patterns.len() - i) appears to be correct for calculating the negative index from the end. However, ensure this aligns with CPython's behavior for sequence patterns with star elements.

---

3488-3502: Good fix for wildcard pattern handling

The improved wildcard detection correctly identifies true wildcards (underscore patterns without name binding) and skips compilation for them, which is an optimization. The distinction between Pattern::MatchAs with both pattern and name as None versus other wildcard patterns is correctly implemented.

---

3519-3708: Comprehensive mapping pattern implementation with rest support

The mapping pattern logic has been significantly improved with:

1. Proper rest pattern handling (**rest)
2. Robust key validation ensuring only literals and attributes
3. Clear duplicate detection using unparse_expr for stable representation
4. Correct stack manipulation for rest dict creation

The implementation correctly builds a rest dict, removes consumed keys, and stores the result. The stack operations are well-documented with comments showing stack state at each step.

---

3926-3932: Correct singleton pattern matching semantics

The change from CompareOperation::Equal to TestOperation::Is for singleton patterns is correct. PEP 634 specifies that singleton patterns (None, True, False) should use identity checks, not equality.

---

4002-4014: Guards implementation completed

The guard implementation correctly:

1. Compiles the guard expression
2. Uses JumpIfFalseOrPop to jump to the fail block if the guard is false
3. Properly handles the stack state

This replaces the previous NotImplementedYet stub.

---

4032-4036: Default case guard handling looks correct

The guard handling for the default case in match statements is properly implemented, using JumpIfFalseOrPop to skip the body if the guard fails.

---

3653-3698: Tests for mapping-rest patterns are already in place

The extra_tests/snippets/syntax_match.py file includes comprehensive tests for mapping patterns with **rest, covering:

• Single-key rest (case {"a": x, **rest}) and empty rest
• Multiple-key rest scenarios
• Edge cases (wildcard fallback, no-match)
• A dedicated test_mapping_comprehensive() function exercising key captures and rest behavior

No additional test coverage is required.

Reviewing files that changed from the base of the PR and between 0bb06ab and 5617d23.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/frame.rs (5 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/str.rs

• vm/src/builtins/dict.rs
• vm/src/types/slot.rs
• vm/src/builtins/bytes.rs
• vm/src/builtins/list.rs
• vm/src/builtins/bytearray.rs
• vm/src/builtins/tuple.rs
• vm/src/builtins/int.rs
• vm/src/frame.rs
• extra_tests/snippets/syntax_match.py
• vm/src/builtins/set.rs

• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Check the WASM package and demo
• GitHub Check: Run tests under miri
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Ensure compilation on various targets

vm/src/builtins/float.rs (1)

203-206: MATCH_SELF flag coverage verified across all builtins

Confirmed that the _MATCH_SELF flag is present on all intended builtins—bool, int, float, bytes, bytearray, str, list, tuple, set, and dict—so no further changes are required.

vm/src/builtins/bool.rs (1)

112-112: ACTION REQUIRED: Confirm MATCH_SELF flag rollout across builtins

The _MATCH_SELF flag on bool (vm/src/builtins/bool.rs:112) correctly enables class-pattern “match self” semantics for booleans. However, our quick grep across vm/src/builtins only finds this single instance:

• vm/src/builtins/bool.rs:112 – #[pyclass(..., flags(_MATCH_SELF))]

No other builtins currently include _MATCH_SELF. To ensure consistent class-pattern matching support, please:

• Verify whether other builtins (e.g., int, float, str, list, dict, etc.) should also carry the MATCH_SELF flag.
• If so, apply the same metadata change to those classes.
• Otherwise, document that bool is intentionally the sole builtin requiring _MATCH_SELF.

compiler/codegen/src/compile.rs (6)

3487-3503: Skip-compiling true wildcards in class patterns is a nice win; double-check AST shape.

Early POP + continue for true wildcards avoids unnecessary work and binding checks. Ensure that ruff’s AST represents “_” as MatchAs { pattern: None, name: None } in this context; if so, this logic is solid. Add a small test covering both positional and keyword wildcards inside a class pattern.

---

3547-3554: Fast-path for empty mapping pattern is correct.

Special-casing {} to immediately POP the subject is faithful to CPython and reduces work.

---

3572-3579: Overflow guard tightened; cast is safe.

Using size > i32::MAX + 1 with the cast warning suppressed is appropriate here.

---

3936-3938: Use of ‘is’ for singletons is correct.

Switching to TestOperation::Is matches Python semantics for None/True/False.

---

4011-4021: Guards: compile and branch on false using JumpIfFalseOrPop to the fail label.

This integrates guard semantics cleanly with the existing fail_pop machinery.

---

4040-4043: Default-case guards compiled consistently.

Compiling the guard and jumping to end if false mirrors CPython behavior.

Reviewing files that changed from the base of the PR and between 5617d23 and 67bbe81.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• compiler/core/src/bytecode.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/frame.rs (8 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/set.rs
• vm/src/builtins/bytes.rs
• vm/src/builtins/bool.rs
• vm/src/builtins/dict.rs
• vm/src/builtins/float.rs
• vm/src/builtins/list.rs
• vm/src/types/slot.rs
• vm/src/builtins/int.rs
• vm/src/builtins/tuple.rs
• vm/src/builtins/bytearray.rs
• extra_tests/snippets/syntax_match.py

• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Check the WASM package and demo
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Ensure compilation on various targets
• GitHub Check: Run tests under miri

vm/src/builtins/str.rs (1)

523-536: Verified _MATCH_SELF flag across builtins

I ran a repo-wide search and confirmed that all the intended built-ins opt into _MATCH_SELF:

• bool (vm/src/builtins/bool.rs:112)
• bytearray (vm/src/builtins/bytearray.rs:173)
• bytes (vm/src/builtins/bytes.rs:135)
• dict (vm/src/builtins/dict.rs:179)
• float (vm/src/builtins/float.rs:204)
• int (vm/src/builtins/int.rs:320)
• list (vm/src/builtins/list.rs:112)
• set (vm/src/builtins/set.rs:532, 949)
• str (vm/src/builtins/str.rs:524)
• tuple (vm/src/builtins/tuple.rs:247)

Remaining verification needed:

• Confirm at runtime that exactly one positional subpattern is enforced (i.e. case str(a, b): against a str should raise TypeError).
• It’d be good to add the proposed str_class_pattern_tests.py (or similar) to lock in that behavior.

Please run those tests manually (or add them to your test suite) and verify the spec-compliant error is raised.

compiler/core/src/bytecode.rs (5)

528-528: LGTM! Properly restored ToBool instruction.

The ToBool instruction has been appropriately restored from its previously commented state, which aligns with the runtime implementation in vm/src/frame.rs.

---

558-561: LGTM! Well-documented PopJumpIfFalse instruction.

The new PopJumpIfFalse instruction is properly documented and follows the existing instruction pattern. The doc comment clearly explains its behavior: "Pop the top of the stack, then pop the next value and jump if it is false."

---

1264-1264: LGTM! Correctly added PopJumpIfFalse to label handling.

The PopJumpIfFalse instruction has been properly integrated into the label_arg() method to ensure it's recognized as a jump instruction with a label target.

---

1338-1338: LGTM! Accurate stack effect calculations.

The stack effects are correctly specified:

• ToBool: 0 (replaces TOS with its boolean value)
• PopJumpIfFalse: -1 (pops one item from stack)

These values accurately reflect the operations performed by each instruction.

Also applies to: 1349-1349

---

1541-1541: LGTM! Display formatting properly implemented.

The new instructions are correctly integrated into the display/disassembly logic.

Also applies to: 1556-1556

compiler/codegen/src/compile.rs (9)

3488-3503: Good improvement: Proper wildcard pattern handling.

The addition of is_true_wildcard logic correctly distinguishes between actual wildcard patterns ("_" without name binding) and named captures, preventing unnecessary pattern compilation for true wildcards. This optimization aligns with CPython's behavior.

---

3521-3535: LGTM! Proper validation for mapping patterns.

Good error handling:

1. Validates that keys and patterns array lengths match
2. Correctly rejects "_" as a rest pattern target with appropriate error message

---

3571-3578: LGTM! Proper overflow check with safe casting.

The overflow check correctly ensures that size doesn't exceed i32::MAX + 1 before casting to u32. The #[allow(clippy::cast_possible_truncation)] is justified here since the check guarantees safety.

---

3582-3616: Good implementation of PEP 634 key validation.

The key validation logic correctly implements PEP 634 requirements:

• Allows literals (number, string, bytes, boolean, None)
• Allows attribute lookups
• Properly detects and reports duplicate keys using stable string representation

---

3662-3705: Complex but correct rest pattern handling.

The rest pattern implementation properly:

1. Creates an empty dict and updates it with the subject
2. Unpacks keys and removes them from the rest dict
3. Correctly manages the stack throughout the operation

The stack comments help track the state at each step, which aids maintainability.

---

3936-3938: Correct implementation: Using Is operator for singleton matching.

The change from CompareOperation::Equal to TestOperation::Is is correct for singleton pattern matching (None, True, False), as per PEP 634 specification.

---

4010-4020: LGTM! Guard implementation with proper boolean conversion.

The guard compilation correctly:

1. Compiles the guard expression
2. Converts to boolean with ToBool
3. Uses PopJumpIfFalse to jump to failure if guard is false

This properly implements the guard semantics for match cases.

---

4039-4043: Guard handling for default case looks correct.

The guard compilation for the default (catch-all) case properly uses JumpIfFalseOrPop to either jump to end if guard is false or continue if true.

---

3294-3295: Verify GetLen Index Calculation Logic

I wasn’t able to find any existing tests in extra_tests/ covering the extraction of elements after a star pattern in sequence matching. Please confirm that the updated expression:

value: (patterns.len() - i).into(),

correctly computes the number of elements following position i (previously (patterns.len() - 1)). If this is intentional:

• Ensure that (patterns.len() - i) aligns with the intended semantics of GetLen when compiling star-pattern sequences.
• Consider adding targeted tests (e.g., sequence patterns with varying lengths and star positions) to validate both edge cases (star at start/end) and typical scenarios.

File: compiler/codegen/src/compile.rs
Lines: 3294–3295

vm/src/frame.rs (5)

3-3: Import of PyTypeFlags is appropriate and used correctly later.
No issues; the flag checks for MAPPING/SEQUENCE/_MATCH_SELF below rely on this.

---

1094-1099: ToBool opcode implementation looks correct.
Pops, converts via try_to_bool, pushes bool. Matches the expected semantics and propagates exceptions properly.

---

1248-1250: PopJumpIfFalse + helper extraction is solid.
Refactoring into pop_jump_if keeps semantics aligned with JumpIfFalse and reduces duplication.

Also applies to: 1970-1986

---

1320-1325: MatchSequence flag check is OK and aligns with the intended semantics.
This matches the retrieved learnings that only certain builtins (list/tuple) should be considered sequences for pattern matching.

Note: I used your prior clarification (learning) that bytes/bytearray/range are not sequences in this context.

---

1345-1349: Correct: KeyError → non-match; other errors propagate.
This mirrors CPython behavior for mapping lookups inside match.

Reviewing files that changed from the base of the PR and between 67bbe81 and ef1ed94.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/frame.rs (5 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/dict.rs
• vm/src/builtins/bytes.rs
• vm/src/builtins/str.rs
• vm/src/builtins/int.rs
• vm/src/builtins/bytearray.rs
• vm/src/builtins/list.rs
• vm/src/builtins/set.rs
• vm/src/builtins/tuple.rs
• vm/src/types/slot.rs
• vm/src/builtins/float.rs
• vm/src/builtins/bool.rs
• extra_tests/snippets/syntax_match.py

• GitHub Check: Check the WASM package and demo
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run tests under miri
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Ensure compilation on various targets

compiler/codegen/src/compile.rs (4)

3522-3578: Enhance mapping pattern validation and error handling.

The validation logic correctly implements PEP 634 requirements but could benefit from clearer error messages and more robust overflow checking.

The implementation properly validates:

• Pattern count matches key count
• Rest pattern cannot be _
• Keys must be literals or attribute lookups
• No duplicate keys

The overflow check and error messages are appropriate for the context.

---

3935-3939: Use TestOperation with Is operator for singleton matching.

The change from CompareOperation with Equal to TestOperation with Is is correct for singleton pattern matching, as singletons should be compared using identity (is) rather than equality (==).

This change aligns with Python's semantics where None, True, and False are compared using identity.

---

4010-4021: Implement guard expression compilation correctly.

The guard implementation is now complete and correct, properly compiling the guard expression and jumping to the failure target when the guard evaluates to false.

The implementation:

• Compiles the guard expression
• Converts to boolean using ToBool
• Jumps to the appropriate failure block if false

---

4039-4043: Handle guards in default match cases.

The guard handling for default cases is implemented correctly, using JumpIfFalseOrPop to jump to the end if the guard fails.

This ensures that even default patterns with guards can fail and continue to the end of the match statement.

vm/src/frame.rs (4)

18-18: Importing PyTypeFlags for flag-driven pattern checks — LGTM

This aligns with the new flag-based recognition in MatchMapping/MatchSequence/MatchClass.

---

23-23: Wtf8Buf import for BUILD_STRING — LGTM

Matches the use in BuildString to collect utf-8 chunks efficiently.

---

1317-1322: MatchSequence flag check looks correct for intended semantics

Checks PyTypeFlags::SEQUENCE. Based on prior guidance, only list and tuple should carry this flag (bytes/bytearray/range are not sequences for pattern matching).

---

1332-1365: MatchKeys aligns with MatchMapping (flag-based) and handles KeyError vs other errors correctly — LGTM

• Stack effect matches CPython: [subject, keys] -> [subject, keys_or_none, values_or_none].
• On missing key (KeyError) returns non-match; other errors propagate. Good.

Reviewing files that changed from the base of the PR and between ef1ed94 and 1984856.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/builtins/type.rs (3 hunks)
• vm/src/frame.rs (3 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/set.rs
• vm/src/builtins/list.rs
• vm/src/builtins/str.rs
• vm/src/builtins/dict.rs
• vm/src/builtins/float.rs
• vm/src/builtins/bytes.rs
• vm/src/builtins/tuple.rs
• vm/src/builtins/bytearray.rs
• vm/src/builtins/bool.rs
• vm/src/types/slot.rs
• vm/src/builtins/int.rs

• GitHub Check: Run tests under miri
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Ensure compilation on various targets
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Check the WASM package and demo

vm/src/builtins/type.rs (4)

235-255: Pattern matching flag inheritance logic looks correct

The updated inherit_patma_flags method properly handles multi-base inheritance by:

1. Checking all bases in order
2. Inheriting the first non-empty COLLECTION_FLAGS found
3. Correctly preventing override of existing flags

The implementation follows Python's semantics where the first base with pattern matching flags wins.

---

269-271: Good defensive check for existing flags

The early return prevents accidental overwriting of collection flags that may have been set elsewhere, maintaining flag integrity.

---

315-316: LGTM: Proper base list passing for flag inheritance

The change correctly passes the full bases slice instead of a single base, enabling proper multi-base inheritance checking.

---

374-375: Static types handled correctly with single-base slice

Creating a single-element slice for static types preserves backward compatibility while using the new multi-base API consistently.

extra_tests/snippets/syntax_match.py (3)

67-70: Good addition of explicit assertions for mapping pattern

Adding explicit assertions for both x and y values improves test clarity and ensures the mapping pattern correctly extracts both values.

---

72-88: Excellent test coverage for mapping rest patterns

The new tests comprehensively cover:

• Basic rest pattern with remaining items
• Empty rest pattern edge case
• Multiple key extraction with rest

This provides good coverage for the **rest pattern functionality.

---

89-106: Comprehensive rest pattern test with multiple keys

The test properly validates that rest patterns correctly collect unmatched keys while preserving matched ones. The progression from 2-key to 3-key matching demonstrates incremental consumption.

compiler/codegen/src/compile.rs (7)

3487-3507: Wildcard pattern handling logic is correct

The implementation properly:

1. Identifies true wildcards (patterns with no name binding)
2. Decrements on_top for all patterns (including wildcards)
3. Pops wildcards from the stack without compiling them

This correctly handles the _ pattern in class matching.

---

3521-3535: Excellent validation for mapping patterns

The implementation includes proper checks for:

1. Key-pattern count mismatch
2. Invalid _ as a rest target (matching Python's syntax rules)

The error messages are clear and helpful.

---

3577-3578: Safe downcast after overflow check

The cast is safe here since the overflow check at line 3572 ensures size <= i32::MAX + 1.

---

3583-3616: Key validation and duplicate detection improvements

The implementation properly:

1. Accepts literals and attribute lookups as required by PEP 634
2. Uses unparse_expr for stable duplicate detection (avoiding Debug format issues)
3. Includes None and bytes literals as valid keys

This is a significant improvement over the previous Debug-based approach.

---

3936-3939: Correct change to use Is operator for singleton patterns

Using TestOperation::Is instead of CompareOperation::Equal is the correct approach for singleton pattern matching, as it properly tests identity rather than equality.

---

4010-4021: Guards properly implemented for match cases

The guard compilation correctly:

1. Evaluates the guard expression
2. Converts to bool
3. Jumps to fail block if false

This matches Python's guard semantics.

---

4039-4043: Default case guard handling looks good

The implementation correctly handles guards in default (catch-all) cases using JumpIfFalseOrPop to either continue or skip the case body.

vm/src/frame.rs (3)

18-24: Import changes and PyTypeFlags usage — LGTM

Consolidating imports and switching to flag-based checks via PyTypeFlags is consistent with the rest of the VM. No issues here.

---

1317-1323: MatchSequence: restrict via SEQUENCE flag — LGTM

Using PyTypeFlags::SEQUENCE here aligns with the intended semantics (list/tuple are sequences; bytes/bytearray/range are not) per prior discussion. Good.

---

1306-1311: Mapping checks in MatchMapping and MatchKeys are now consistent

• Both opcodes in vm/src/frame.rs use the PyTypeFlags::MAPPING flag:
  • Line 1307: subject.class().slots.flags.contains(PyTypeFlags::MAPPING)
  • Line 1330: same flag check in the MatchKeys path
• A repository-wide search for PyMapping::check in vm/src/** found no other references in the match opcode implementations.

All mapping-related checks in these opcodes now uniformly rely on the type flag.

Reviewing files that changed from the base of the PR and between 1984856 and c965f78.

• Lib/test/test_patma.py is excluded by !Lib/**

• vm/src/builtins/type.rs (3 hunks)
• vm/src/frame.rs (3 hunks)

• GitHub Check: Check the WASM package and demo
• GitHub Check: Run tests under miri
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Ensure compilation on various targets
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Run rust tests (ubuntu-latest)

vm/src/builtins/type.rs (2)

315-317: Good call-site integration.

Propagating flags from all bases in new_heap_inner aligns with the new API and the “first base wins” behavior.

---

373-376: Static types: confirm ABC-derived flags aren’t needed at creation.

new_static inherits flags from the single base but doesn’t consult abc_tpflags. That’s likely intentional (builtins set explicit flags). Please confirm no static type relies on ABCMeta-provided flags at init; otherwise consider calling check_abc_tpflags() here too.

Would you like a quick repo scan to list static builtins that set MAPPING/SEQUENCE explicitly to ensure coverage?

vm/src/frame.rs (1)

1306-1311: Add MAPPING flag to built-in mapping types

Our search across vm/src/builtins/*.rs found no #[pyclass(..., flags = PyTypeFlags::MAPPING, ...)] annotations (the rg for flags.*MAPPING returned zero matches). In particular:

• vm/src/builtins/dict.rs​:

  #[pyclass(module = false, name = "dict", unhashable = true, traverse)]

  (no flags = PyTypeFlags::MAPPING)
• vm/src/builtins/mappingproxy.rs​:

  #[pyclass(module = false, name = "mappingproxy", traverse)]

  (no flags = PyTypeFlags::MAPPING)

Because MatchMapping now simply checks the type’s PyTypeFlags::MAPPING bit, failing to set it means neither dict nor mappingproxy will be recognized as mappings at runtime.

Please update these two #[pyclass] attributes to include flags = PyTypeFlags::MAPPING. For example:

 #[pyclass(
-   module = false,
-   name = "dict",
-   unhashable = true,
-   traverse
+   module = false,
+   name = "dict",
+   unhashable = true,
+   traverse,
+   flags = PyTypeFlags::MAPPING
 )]

 #[pyclass(
-   module = false,
-   name = "mappingproxy",
-   traverse
+   module = false,
+   name = "mappingproxy",
+   traverse,
+   flags = PyTypeFlags::MAPPING
 )]

Optionally, review other types implementing the AsMapping trait (e.g. in tuple.rs, list.rs, range.rs, etc.) and decide whether they should likewise carry the mapping flag or remain sequence-only.

⛔ Skipped due to learnings

Learnt from: youknowone
PR: RustPython/RustPython#6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.523Z
Learning: In the RustPython codebase, only certain builtin types should be marked with the SEQUENCE flag for pattern matching. List and tuple are sequences, but bytes, bytearray, and range are not considered sequences in this context, even though they may implement sequence-like protocols.

Learnt from: youknowone
PR: RustPython/RustPython#6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.523Z
Learning: In RustPython's pattern matching implementation, only certain builtin types should have the SEQUENCE flag: list and tuple are confirmed sequences. The user youknowone indicated that bytes, bytearray are not considered sequences in this context, even though they implement sequence-like protocols.

Reviewing files that changed from the base of the PR and between c965f78 and f4543f5.

• Lib/test/test_patma.py is excluded by !Lib/**

• compiler/codegen/src/compile.rs (7 hunks)
• extra_tests/snippets/syntax_match.py (1 hunks)
• vm/src/builtins/bool.rs (1 hunks)
• vm/src/builtins/bytearray.rs (1 hunks)
• vm/src/builtins/bytes.rs (1 hunks)
• vm/src/builtins/dict.rs (1 hunks)
• vm/src/builtins/float.rs (1 hunks)
• vm/src/builtins/int.rs (1 hunks)
• vm/src/builtins/list.rs (1 hunks)
• vm/src/builtins/set.rs (2 hunks)
• vm/src/builtins/str.rs (1 hunks)
• vm/src/builtins/tuple.rs (1 hunks)
• vm/src/builtins/type.rs (3 hunks)
• vm/src/frame.rs (3 hunks)
• vm/src/types/slot.rs (1 hunks)

• vm/src/builtins/bool.rs
• vm/src/builtins/dict.rs
• vm/src/builtins/tuple.rs
• vm/src/builtins/str.rs
• vm/src/types/slot.rs
• vm/src/builtins/list.rs
• vm/src/builtins/set.rs
• vm/src/builtins/bytearray.rs
• vm/src/builtins/float.rs
• vm/src/builtins/bytes.rs
• extra_tests/snippets/syntax_match.py
• vm/src/builtins/type.rs

• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Check the WASM package and demo
• GitHub Check: Run tests under miri
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Check Rust code with rustfmt and clippy
• GitHub Check: Ensure compilation on various targets

vm/src/frame.rs (4)

18-18: Flag imports and common utilities consolidation — LGTM

Importing PyTypeFlags and consolidating BoxVec/PyMutex/Wtf8Buf is appropriate for the new flag-driven matching and BuildString path.

Also applies to: 23-23

---

1325-1391: MatchKeys logic is robust and CPython-aligned — using get with a sentinel, with getitem fallback

• Using vm.get_method(..., "get").transpose()? correctly propagates attribute-access errors.
• The dummy sentinel and identity check avoid KeyError and missing side-effects.
• Falling back to getitem when get is absent keeps behavior correct for non-dict mappings.

---

1393-1512: Verify built-in MATCH_SELF annotations before adding tests

The ripgrep output shows that only bool is defined with flags(_MATCH_SELF); the other built-in types (int, str, float, tuple, list, dict) aren’t annotated and will follow the “no match_args” error path rather than MATCH_SELF semantics. Please confirm your intended behavior:

• If you plan to support MATCH_SELF for those types, add flags(_MATCH_SELF) to their #[pyclass(...)] in:
  • vm/src/builtins/int.rs
  • vm/src/builtins/str.rs
  • vm/src/builtins/float.rs
  • vm/src/builtins/tuple.rs
  • vm/src/builtins/list.rs
  • vm/src/builtins/dict.rs
• Otherwise, limit the new pytest cases to:
  • bool(x) extracting the subject itself (MATCH_SELF happy path) and rejecting bool(x, y) with the corresponding TypeError.
  • For int(x)/str(x)/etc., asserting the “C() accepts 0 positional sub-patterns but 1 were given” error from the no-match_args branch.

Once you’ve confirmed the desired flag coverage, you can proceed to draft tests that align with the actual implementation.

---

1306-1311: Flag coverage gaps in mappingproxy and list — action required

The mapping (MAPPING) and sequence (SEQUENCE) flags are correctly driving pattern‐matching in frame.rs, but our downstream inspection uncovered two missing flag annotations:

• mappingproxy
  The PyMappingProxy class in vm/src/builtins/mappingproxy.rs currently reads:

  #[pyclass(module = false, name = "mappingproxy", traverse)]
  #[derive(Debug)]
  pub struct PyMappingProxy { … }

  It must carry the MAPPING flag so that MatchMapping sees it. For consistency with PyDict, change it to:

  #[pyclass(
      module = false,
      name = "mappingproxy",
      traverse,
  -   // missing flags
  +   flags(BASETYPE, MAPPING, _MATCH_SELF),
  )]
  #[derive(Debug)]
  pub struct PyMappingProxy { … }

  This ensures subject.class().slots.flags.contains(PyTypeFlags::MAPPING) returns true for mappingproxy.

• list
  The PyList class in vm/src/builtins/list.rs currently reads:

  #[pyclass(module = false, name = "list", unhashable = true, traverse)]
  #[derive(Default)]
  pub struct PyList { … }

  It likewise needs the SEQUENCE flag so that MatchSequence recognizes lists. Update it to:

  #[pyclass(
      module = false,
      name = "list",
      unhashable = true,
      traverse,
  -   // missing flags
  +   flags(BASETYPE, SEQUENCE, _MATCH_SELF),
  )]
  #[derive(Default)]
  pub struct PyList { … }

  This makes subject.class().slots.flags.contains(PyTypeFlags::SEQUENCE) true for lists.

All other builtins—dict/mappingproxy for mappings and only tuple (and now list) for sequences—are correctly flagged, and bytes/bytearray/range remain unflagged as intended. Apply these changes to fully align flag coverage with CPython’s pattern-matching rules in both the mapping check (lines 1306–1311) and sequence check (lines 1317–1323) of vm/src/frame.rs.

⛔ Skipped due to learnings

Learnt from: youknowone
PR: RustPython/RustPython#6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.523Z
Learning: In the RustPython codebase, only certain builtin types should be marked with the SEQUENCE flag for pattern matching. List and tuple are sequences, but bytes, bytearray, and range are not considered sequences in this context, even though they may implement sequence-like protocols.

Learnt from: youknowone
PR: RustPython/RustPython#6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.523Z
Learning: In RustPython's pattern matching implementation, only certain builtin types should have the SEQUENCE flag: list and tuple are confirmed sequences. The user youknowone indicated that bytes, bytearray are not considered sequences in this context, even though they implement sequence-like protocols.

vm/src/builtins/int.rs (1)

320-322: Add _MATCH_SELF to int: aligns with class-pattern “self” semantics

Good call adding the _MATCH_SELF flag so patterns like case int(x) bind the subject itself. This matches CPython’s Py_TPFLAGS_MATCH_SELF behavior and is consistent with the wider PR adding this flag across builtins.

Follow-ups:

• Please make sure bool also sets _MATCH_SELF (bool is a subclass of int and typically participates in these patterns).
• Consider adding small runtime tests to cover:
  • match 42: case int(): ...
  • match 42: case int(x): assert x == 42
  • Negative: match 42: case int(x, y): ... should not match.

compiler/codegen/src/compile.rs (6)

3486-3506: on_top accounting with wildcard subpatterns is consistent

You decrement pc.on_top before checking for a true wildcard, and explicitly Pop the wildcard value. Given we just unpacked total items and bumped on_top accordingly, consuming one stack item per iteration (wildcard or not) keeps on_top correct. No change requested.

---

3556-3579: Early length check + overflow guard: good prefiltering

• GetLen >= size is a reasonable fast-fail before the more precise MatchKeys.
• The overflow guard (size > i32::MAX + 1) mirrors CPython’s intent; casting to u32 afterward is safe.

LGTM.

---

3623-3650: MatchKeys + None check pipeline reads cleanly

• Building the keys tuple, calling MatchKeys, and testing against None with IsNot is straightforward and matches the VM changes described in the PR.
• Unpacking the resulting values tuple and updating pc.on_top accordingly looks consistent.

LGTM.

---

3936-3940: Singleton patterns should use identity (is) — correct

Switching to TestOperation::Is for None/True/False matches CPython semantics. Good fix.

---

4010-4021: Guard compilation paths look correct for both non-default and default cases

• Non-default cases: compile guard, ToBool, and jump to the pattern-failure target — matches the intended control flow.
• Default case: JumpIfFalseOrPop to end is the right behavior.

No issues spotted.

Also applies to: 4039-4043

---

3519-3536: Keep Disallowing **_ in Mapping Patterns

According to the Python structural‐pattern‐matching specification, mapping patterns inherently ignore any extra keys not listed in the pattern, so a “rest wildcard” is already redundant. The PEPs and official documentation explicitly state that while **rest is supported to capture the remainder, using **_ as a wildcard is disallowed because it would have no semantic effect.

• PEP 636 (Tutorial) notes: “Mapping patterns… support a wildcard **rest. (But **_ would be redundant, so it is not allowed.)” (peps.python.org)
• PEP 622 (Specification) likewise defines **capture_pattern for mappings and states that **_ is invalid due to its no-op nature. (peps.python.org)

Please retain the existing syntax‐error behavior for **_ in mapping patterns. This enforces clarity (avoiding a no-op wildcard) and keeps consistency with the language design.

Likely an incorrect or invalid review comment.