crates/vm/src/stdlib/typevar.rs (1)

95-107: ⚠️ Potential issue | 🟠 Major

Python call while holding constraints lock.

self.evaluate_constraints.call((1i32,), vm)? at Line 101 executes Python code while constraints is locked. If the called code accesses __constraints__ on the same TypeVar, this deadlocks (non-reentrant mutex). The same issue exists in __bound__ (Line 116). Consider cloning the evaluator, dropping the lock, calling, then re-acquiring to store.

Proposed fix for `__constraints__`

 fn __constraints__(&self, vm: &VirtualMachine) -> PyResult {
-    let mut constraints = self.constraints.lock();
-    if !vm.is_none(&constraints) {
-        return Ok(constraints.clone());
+    {
+        let constraints = self.constraints.lock();
+        if !vm.is_none(&constraints) {
+            return Ok(constraints.clone());
+        }
     }
-    let r = if !vm.is_none(&self.evaluate_constraints) {
-        *constraints = self.evaluate_constraints.call((1i32,), vm)?;
-        constraints.clone()
-    } else {
-        vm.ctx.empty_tuple.clone().into()
-    };
-    Ok(r)
+    if !vm.is_none(&self.evaluate_constraints) {
+        let value = self.evaluate_constraints.call((1i32,), vm)?;
+        *self.constraints.lock() = value.clone();
+        Ok(value)
+    } else {
+        Ok(vm.ctx.empty_tuple.clone().into())
+    }
 }

Apply the same pattern to __bound__.

crates/vm/src/stdlib/typevar.rs (2)

94-107: ⚠️ Potential issue | 🟠 Major

Python call while holding mutex lock in __constraints__.

Line 101 calls self.evaluate_constraints.call((1i32,), vm)? while the constraints mutex is held (locked at Line 96). If the callable transitively accesses __constraints__ on the same TypeVar, this will deadlock on a non-reentrant PyMutex. Consider cloning the evaluator reference and releasing the lock before making the call.

Proposed fix: release lock before Python call

 fn __constraints__(&self, vm: &VirtualMachine) -> PyResult {
-    let mut constraints = self.constraints.lock();
-    if !vm.is_none(&constraints) {
-        return Ok(constraints.clone());
+    {
+        let constraints = self.constraints.lock();
+        if !vm.is_none(&constraints) {
+            return Ok(constraints.clone());
+        }
     }
-    let r = if !vm.is_none(&self.evaluate_constraints) {
-        *constraints = self.evaluate_constraints.call((1i32,), vm)?;
-        constraints.clone()
-    } else {
-        vm.ctx.empty_tuple.clone().into()
-    };
-    Ok(r)
+    if !vm.is_none(&self.evaluate_constraints) {
+        let value = self.evaluate_constraints.call((1i32,), vm)?;
+        *self.constraints.lock() = value.clone();
+        Ok(value)
+    } else {
+        Ok(vm.ctx.empty_tuple.clone().into())
+    }
 }

---

109-122: ⚠️ Potential issue | 🟠 Major

Same issue: Python call while holding bound mutex lock.

Line 116 calls self.evaluate_bound.call((1i32,), vm)? while bound is locked. Apply the same drop-before-call pattern.

Proposed fix

 fn __bound__(&self, vm: &VirtualMachine) -> PyResult {
-    let mut bound = self.bound.lock();
-    if !vm.is_none(&bound) {
-        return Ok(bound.clone());
+    {
+        let bound = self.bound.lock();
+        if !vm.is_none(&bound) {
+            return Ok(bound.clone());
+        }
     }
-    let r = if !vm.is_none(&self.evaluate_bound) {
-        *bound = self.evaluate_bound.call((1i32,), vm)?;
-        bound.clone()
-    } else {
-        vm.ctx.none()
-    };
-    Ok(r)
+    if !vm.is_none(&self.evaluate_bound) {
+        let value = self.evaluate_bound.call((1i32,), vm)?;
+        *self.bound.lock() = value.clone();
+        Ok(value)
+    } else {
+        Ok(vm.ctx.none())
+    }
 }

crates/codegen/src/symboltable.rs (1)

952-987: ⚠️ Potential issue | 🟠 Major

"format" should be registered as a symbol in the annotation scope for consistency.

The annotation scope adds "format" to varnames (line 969) but never calls register_name() to add it to the symbols map. This is inconsistent with TypeAlias value scopes (line 1508) and type-parameter bound/default scopes (line 2015), which both use register_name("format", SymbolUsage::Parameter, ...) to register "format" as a parameter symbol.

While the current code works because emit_format_validation() uses LoadFast(0) to access format by position, the inconsistency means future code that inspects symbol metadata or scope information will not find "format" in the annotation scope's symbols map.

Call register_name("format", SymbolUsage::Parameter, TextRange::default()) after pushing the annotation table to the stack (after line 975), following the same pattern used elsewhere:

Proposed fix

         self.tables.push(*annotation_table);
         // Save parent's varnames and seed with existing annotation varnames (e.g., "format")
         self.varnames_stack
             .push(core::mem::take(&mut self.current_varnames));
         self.current_varnames = self.tables.last().unwrap().varnames.clone();
+        // Register "format" as a parameter symbol (varnames was already seeded above)
+        self.register_name("format", SymbolUsage::Parameter, TextRange::default())?;
 
         if can_see_class_scope && !self.future_annotations {