Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/codegen/src/compile.rs`:
- Around line 5186-5192: The END_FOR/PopIter emission uses iter.range() which
attributes line events to the iterable expression instead of the for-statement;
in compile_for capture the for statement's range at the start (e.g. let
stmt_range = self.current_source_range or similar) and then replace the later
set_source_range(iter.range()) calls with set_source_range(stmt_range) before
emitting Instruction::EndFor and Instruction::PopIter (also update the similar
block at the other spot referenced), ensuring you reference compile_for,
iter.range(), Instruction::EndFor, Instruction::PopIter, set_source_range and
current_source_range when making the change.

In `@crates/vm/src/frame.rs`:
- Around line 484-502: The tracing path (vm.use_tracing) updates prev_line
before the monitoring block, causing monitoring::fire_line to be suppressed when
tracing also fires a Line event; change the update so prev_line is only set once
after both tracing and monitoring checks (i.e., move the prev_line = line
assignment to after the monitoring block) or add a clear comment if sharing the
"new line" state is intentional; refer to symbols vm.use_tracing, prev_line,
monitoring::fire_line, monitoring_mask, monitoring::EVENT_LINE,
Instruction::Resume, and Instruction::ExtendedArg to locate the code to modify.
- Around line 2046-2121: Extract the duplicated branch-monitoring block into a
shared helper (suggested name fire_branch_event) and replace the repeated blocks
in Instruction::PopJumpIfNone, Instruction::PopJumpIfNotNone and the pop_jump_if
implementation with a single call: compute src_offset, branch_taken, taken_dest
(target.0 * 2) and fallthrough_dest (self.lasti() * 2) at each site, then call
self.fire_branch_event(vm, src_offset, branch_taken, taken_dest,
fallthrough_dest). The helper should read vm.state.monitoring_events, decide
dest_offset from branch_taken, and call fire_branch_right or fire_branch_left as
before; mark it #[inline] and keep the same semantics and arguments (vm,
self.code, src_offset, dest_offset).

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 372-378: The is_disable function relies on fragile class name
checks and should instead compare the callback result by identity to the actual
DISABLE sentinel; update MonitoringState (similar to how missing/MISSING is
stored) to hold the DISABLE singleton and initialize it where monitor module
singletons are created, then change is_disable to accept the VM/MonitoringState
and return true only when the passed obj pointer/identity equals
MonitoringState::DISABLE (and still exclude None via vm.is_none(obj)); reference
the is_disable function, MonitoringState, and the DISABLE sentinel when making
the change.

---

Outside diff comments:
In `@crates/vm/src/frame.rs`:
- Around line 715-730: The call to vm.fire_exception_handled(...) inside
unwind_blocks (triggered when closing a generator in the is_gen_exit branch)
must not use ? or propagate errors because a failing EXCEPTION_HANDLED callback
can abort handler setup; change the code around the fire_exception_handled
invocation so it catches Err(e) locally (e.g., match or if let Err(e) =
vm.fire_exception_handled(...)) and logs or records the error instead of
returning it, allowing the subsequent exception-handler setup code in
unwind_blocks (the handler creation and attachment logic that follows the
close_result path) to always run; reference vm.fire_exception_handled,
unwind_blocks, is_gen_exit, and the local variable err when implementing the
local error handling.
- Around line 818-860: The gen_throw path currently swallows errors from
monitoring callbacks (fire_py_throw, fire_raise, fire_py_unwind) using "let _ =
…", creating an inconsistency with the main run loop which replaces the original
exception when a monitoring callback errors; change the gen_throw calls to
handle the Result the same way as in run: capture the Result from
monitoring::fire_py_throw / monitoring::fire_raise / monitoring::fire_py_unwind
and if it Errs, propagate that error (return Err(err) or otherwise replace the
current exception with the monitoring error) instead of discarding it; locate
these calls in gen_throw (the block that checks vm.state.monitoring_events and
calls fire_py_throw/fire_raise/fire_py_unwind) and apply the same
replacement/propagation pattern used in run.

---

Nitpick comments:
In `@crates/derive-impl/src/pymodule.rs`:
- Around line 840-847: meta.module()? is being called twice (for has_module and
module_name); cache its result into a local like let module_opt = meta.module()?
and use that for both checks, then refactor to a single branch: if
module_opt.is_none() { let structseq_attr = &mut args.attrs[self.inner.index];
structseq_attr.fill_nested_meta("module", || parse_quote! { module =
`#module_value` })? } else set module_name from module_opt.unwrap_or_else(...).
Replace both meta.module()? uses with the cached module_opt and update the
module_name/has_module logic accordingly (referencing meta.module, has_module,
module_name, structseq_attr, args.attrs, self.inner.index, and
fill_nested_meta).

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Line 356: Remove the decorative comment line "// ── Event dispatch
──────────────────────────────────────────────────────" from
crates/vm/src/stdlib/sys/monitoring.rs; locate the "Event dispatch" separator
comment and delete that single line so the file conforms to the guideline
disallowing decorative section separators (no other logic changes required).
- Around line 265-275: Replace the hardcoded magic numbers (18, 8, 9) used
around the state.callbacks.insert/remove calls in monitoring.rs with named
constants derived from the event bitflags/enum (e.g., BRANCH, BRANCH_LEFT,
BRANCH_RIGHT) so the mapping is stable if enum order changes; update the checks
using event_id and the tuple keys passed to state.callbacks.insert and
state.callbacks.remove to use EventFlags::BRANCH.bits() /
EventFlags::BRANCH_LEFT.bits() / EventFlags::BRANCH_RIGHT.bits() or the
equivalent event ID constants used by your event enum, and apply the same change
in both the insert (register) and remove (unregister) branches where tool, func,
and event_id are used.

In `@crates/vm/src/vm/interpreter.rs`:
- Around line 127-128: Replace the fully-qualified type used to initialize
monitoring_events with the already-imported short name: change the initializer
from crossbeam_utils::atomic::AtomicCell::new(0) to AtomicCell::new(0) so the
field monitoring_events uses the existing AtomicCell import; no other behavior
change required.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/vm/src/frame.rs`:
- Around line 2048-2066: The monitoring helper fire_branch_event should not
swallow errors: change its signature to return PyResult<()> and propagate
failures with the ? operator from within it; then update all call sites (e.g.,
in Instruction::PopJumpIfNone, Instruction::PopJumpIfNotNone, pop_jump_if,
execute_for_iter and any places that call fire_branch_left/fire_branch_right
variants) to use the ?-propagating call instead of ignoring results, adjust
those functions to return PyResult where needed, and ensure branch-taking logic
still performs self.jump(target) before returning Ok(None) so the propagated
error bubbles up to the instruction executor.
- Around line 1437-1450: The JUMP monitoring callback result is currently
ignored (let _ = crate::stdlib::sys::monitoring::fire_jump(...)) which swallows
errors; replace that ignored call with a propagated result (use the ? operator
or otherwise return the Err) so failures in fire_jump bubble up like other
monitoring events. Specifically, update the block in the same scope that calls
fire_jump so it calls crate::stdlib::sys::monitoring::fire_jump(vm, self.code,
src_offset, dest.0 * 2)?; and ensure the enclosing function’s signature and call
sites return Result/propagate errors accordingly (adjust types where necessary
to match other monitoring event handlers).

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Line 371: Remove the decorative separator comment "// ── Event dispatch
──────────────────────────────────────────────────────" in
crates/vm/src/stdlib/sys/monitoring.rs and either delete it or replace it with a
short, value-adding comment (e.g., "// Event dispatch") using a plain `//` or a
doc comment if documentation is needed; ensure no decorative characters remain
so the section follows the project's comment style.

---

Outside diff comments:
In `@crates/vm/src/frame.rs`:
- Around line 2878-2935: The C_RAISE monitoring call is currently ignored in the
Err branch; update the Err arm of the callable.call match to propagate errors
from monitoring::fire_c_raise just like the Ok arm does for
monitoring::fire_c_return — i.e., replace the discarded call (let _ =
monitoring::fire_c_raise(...);) with a ?-propagated call
(monitoring::fire_c_raise(...)?;) so that errors from fire_c_raise bubble up;
ensure this change is applied around the call_arg0 check in the Err branch where
call_arg0, is_python_call, and offset are used.
- Around line 797-833: The monitoring callbacks (fire_py_throw, fire_raise and
the PY_UNWIND branch) currently ignore returned errors; change each call site in
the generator throw path to check the Result and, on Err, replace the active
exception with the returned error (same behavior as the main RAISE/RERAISE
handling): after calling monitoring::fire_py_throw or monitoring::fire_raise,
match the Result, and on Err(err) set exception = err (and update traceback via
exception.set_traceback_typed(...) as done earlier), then stop ignoring the
error so the new exception is raised; apply the same pattern for the PY_UNWIND
branch mentioned (lines near fire_py_throw/fire_raise), referencing the
functions fire_py_throw, fire_raise, PY_UNWIND, and the local exception variable
to locate edits.

---

Duplicate comments:
In `@crates/codegen/src/compile.rs`:
- Around line 5186-5191: The END_FOR and PopIter emissions are using
iter.range() for source attribution which misattributes multiline
for-statements; in compile_for capture the for-statement's source range at the
start (e.g. let stmt_range = self.current_source_range or similar) and reuse
that stored stmt_range when calling self.set_source_range(...) before
emit!(self, Instruction::EndFor) and emit!(self, Instruction::PopIter) (also
update the other occurrence around the second END_FOR/implicit-return block),
rather than using iter.range().

In `@crates/vm/src/frame.rs`:
- Around line 485-502: The code updates prev_line inside the tracing block
before running the monitoring checks, which can suppress LINE monitoring
(prev_line influences the monitoring::fire_line call); move the prev_line
assignment so it only happens once after both the tracing and monitoring blocks
(i.e., compute line as now, run the monitoring checks that use prev_line and
possibly call monitoring::fire_line, then set prev_line = line), ensuring
Instruction::Resume / Instruction::ExtendedArg exclusions remain unchanged and
keeping monitoring_mask and monitoring::fire_instruction/fire_line usage intact.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/derive-impl/src/pymodule.rs`:
- Around line 233-243: Insert a call to PyModule::__init_dict_from_def after
creating the child module and before calling child.__init_methods so the
sequence in the generated block around `#mod_ident`::module_def(ctx) ->
create_module(vm) becomes: create_module(vm).unwrap();
PyModule::__init_dict_from_def(vm, &child); child.__init_methods(vm).unwrap();
`#mod_ident`::module_exec(vm, &child).unwrap(); and keep the subsequent conversion
and vm.__module_set_attr as-is; also replace the duplicate meta.module()? usage
by capturing it once (e.g., let module_info = meta.module()?; let has_module =
module_info.is_some();) and use module_info for the unwrap_or_else call.

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 353-368: The monitoring lock is held while calling into the Python
runtime in all_events (vm.state.monitoring.lock() surrounding vm.ctx.new_int and
all_events.set_item), which risks deadlock; instead, while holding the lock
iterate EVENT_NAMES.iter().take(UNGROUPED_EVENTS_COUNT) and TOOL_LIMIT to
compute and store (event_name, tools_mask) pairs in a local Vec, then drop the
lock and loop over that Vec to call vm.ctx.new_int(...) and
all_events.set_item(...). Keep references to EVENT_NAMES,
UNGROUPED_EVENTS_COUNT, TOOL_LIMIT, and the all_events dict unchanged, only
moving the Python calls after the lock is released.
- Around line 249-255: free_tool_id has a TOCTOU race because it calls
clear_tool_id (which locks and releases) and then re-locks to clear tool_names,
allowing concurrent set_events/set_local_events to re-populate events for a
freed slot; fix by extracting the clearing logic from clear_tool_id into an
internal helper that accepts &mut MonitoringState (e.g., fn
clear_tool_state_locked(state: &mut MonitoringState, tool: usize) ) and then
change free_tool_id to acquire vm.state.monitoring.lock() once, call
check_valid_tool without releasing, invoke the new helper to clear
global_events/local_events/callbacks/disabled and update_events_mask while still
holding the lock, and finally set state.tool_names[tool] = None; update or
replace callers of clear_tool_id to either use the new helper when they already
hold the lock or keep clear_tool_id as a thin wrapper that locks and calls the
helper.

---

Outside diff comments:
In `@crates/vm/src/frame.rs`:
- Around line 818-858: The monitoring callback results (fire_py_throw,
fire_raise, fire_py_unwind) are being ignored, which can drop monitoring errors;
change these call sites inside the generator throw/unwind path to mirror the
main run loop behavior by checking the callback return and replacing the current
exception when the callback returns a new/failed exception: call fire_py_throw
and fire_raise, inspect their Result/Option, and if they indicate an error or
provide a replacement exception, set the local exception (the value passed into
unwind_blocks / used for reporting) to that returned exception before
continuing; do the same for fire_py_unwind in the Err branch so the exception
propagated by unwind_blocks/run reflects any replacement from the monitoring
callback.
- Around line 2878-2935: Compute call_arg0 whenever any of the monitor bits
monitoring::EVENT_CALL, monitoring::EVENT_C_RETURN, or monitoring::EVENT_C_RAISE
are enabled (so arg0 is available for all three callbacks), but only invoke
monitoring::fire_call if EVENT_CALL is set and only invoke
monitoring::fire_c_return / monitoring::fire_c_raise when their respective bits
(EVENT_C_RETURN, EVENT_C_RAISE) are set; when calling monitoring::fire_c_raise,
propagate/replace the active exception if the callback returns an Err (i.e.,
return that error instead of discarding it). Ensure you update the code around
call_arg0 creation and the match arms for Ok/Err to check the specific event
bits (use monitoring::EVENT_C_RETURN and monitoring::EVENT_C_RAISE) and to
handle a failing fire_c_raise by replacing the returned Err as the function’s
Err.

---

Duplicate comments:
In `@crates/codegen/src/compile.rs`:
- Around line 5186-5201: In compile_for, the code still uses iter.range() for
source attribution causing END_FOR/implicit return to be misattributed on
multiline for statements; capture the for statement's range at the start of
compile_for (e.g., let stmt_range = for_stmt.range() or similar) and replace
uses of iter.range() in the places shown (the set_source_range calls before
emitting Instruction::EndFor/PopIter and the final set_source_range call) with
stmt_range so all END_FOR/implicit return attribution uses the for statement
range rather than the iterator expression's range.

In `@crates/vm/src/frame.rs`:
- Around line 485-502: The tracing block currently updates prev_line before the
monitoring block causing LINE events to be suppressed when both tracing and
monitoring are enabled; introduce a separate prev_line_monitor (initialized to
the same starting line where prev_line is initialized) and use it in the
monitoring comparison and update (replace uses of prev_line in the monitoring
block with prev_line_monitor and set prev_line_monitor = line after firing
monitoring events) while leaving prev_line behavior for tracing unchanged;
update references around Instruction::Resume / Instruction::ExtendedArg,
self.code.locations[idx].0.line.get(), monitoring::fire_line and
monitoring::fire_instruction, and vm.state.monitoring_events.load() to use the
new monitor-specific tracker.
- Around line 3124-3181: In execute_for_iter (the match on next_obj) the
branch-monitoring logic is duplicated in both Ok(PyIterReturn::Return(...)) and
Ok(PyIterReturn::StopIteration(...)); extract the common monitoring block by
first computing the differing pieces (e.g., src_offset = (self.lasti() - 1) * 2,
a boolean/flag for branch_taken or an enum indicating Left vs Right, and the
dest_offset which is either self.lasti() * 2 or jump_target.0 * 2) and then call
a single helper (reuse fire_branch_event or create one) that takes vm,
self.code, src_offset, dest_offset and the branch type; replace the two
identical monitoring if-blocks with this single call so only the differing
values are computed per arm and the shared logic is centralized.

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Line 371: Remove the decorative separator comment "// ── Event dispatch
──────────────────────────────────────────────────────" and replace it with a
concise, meaningful comment (e.g. "// Event dispatch" ) or a doc-comment if
documentation is needed; locate the separator in the event dispatch section
where the comment text "Event dispatch" appears and update the comment to follow
the no-decorative-separators guideline (affecting the event dispatch block).

---

Nitpick comments:
In `@crates/derive-impl/src/pymodule.rs`:
- Around line 840-841: Collapse the duplicate calls to meta.module() by calling
it once into a local binding (e.g., let module_opt = meta.module()?) and then
derive has_module from module_opt.is_some() and module_name from
module_opt.unwrap_or_else(|| args.context.name.clone()); update the existing
variables has_module and module_name to use that single binding so the attribute
is parsed only once.

In `@crates/vm/src/frame.rs`:
- Around line 1437-1450: This change touches bytecode instruction handling
around lasti(), jump(), and the call to
crate::stdlib::sys::monitoring::fire_jump guarded by EVENT_JUMP; before
finalizing, perform a clean build to ensure generated artifacts reflect the
instruction changes by removing affected cargo build caches and stale .pyc files
(run the prescribed commands to delete target/debug/build/rustpython-* and
remove .pyc files), then rebuild and run tests to verify no bytecode/monitoring
regressions occur.

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 676-677: The function fire_stop_iteration is currently unused
(marked with #[allow(dead_code)]) so STOP_ITERATION events are never emitted;
remove the allow attribute and call fire_stop_iteration from the StopIteration
raise sites in frame.rs — specifically where FOR_ITER implicitly raises and
where generator/iterator exhaustion is handled — passing the same
context/arguments used by other monitoring calls (keep the function signature of
fire_stop_iteration intact), and ensure the STOP_ITERATION bit (bit 10 /
MonitoringEvents::STOP_ITERATION) is emitted so registered callbacks receive the
event.
- Around line 280-290: Replace the magic numeric literals (18, 8, 9) in the
register_callback logic with named values from the MonitoringEvents bitflags:
compute the branch-related IDs from MonitoringEvents::BRANCH,
MonitoringEvents::BRANCH_LEFT and MonitoringEvents::BRANCH_RIGHT (e.g. use their
.bits() or test membership via MonitoringEvents::from_bits_truncate(event_id) /
.contains(...)) and use those constants when inserting/removing entries in
state.callbacks and when testing event_id; update the conditional that currently
reads `if event_id == 18` and the two inserts/removes that use 8 and 9 to
reference the corresponding MonitoringEvents-derived identifiers or contains
checks instead of raw numbers.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/vm/src/frame.rs`:
- Around line 2943-2950: The monitoring callback fire_c_raise is currently
invoked with "let _ =" which drops any error; change the call in the Err(exc)
arm so that if monitoring::fire_c_raise(vm, self.code, offset, &callable, arg0)
returns Err(mon_exc) you propagate or replace the current exception (i.e.,
return Err(mon_exc) or otherwise replace exc with the callback's error) instead
of discarding it; update the invocation around the symbols call_arg0,
is_python_call, self.lasti(), code, and callable so it mirrors the
error-handling behavior used by the other monitoring handlers (RAISE, PY_UNWIND,
PY_THROW) in this file.

---

Duplicate comments:
In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 353-368: In all_events, avoid holding vm.state.monitoring.lock()
across calls into the Python VM: while iterating
EVENT_NAMES/UNGROUPED_EVENTS_COUNT and TOOL_LIMIT you should collect the
(event_name, tools_mask) pairs into a temporary Vec under the lock (compute
event_bit and tools_mask as now), then drop the lock and iterate the Vec to call
all_events.set_item(*event_name, vm.ctx.new_int(tools_mask).into(), vm); this
prevents deadlocks if set_item triggers code that re-acquires
vm.state.monitoring.
- Line 371: Remove the decorative separator comment "// ── Event dispatch
──────────────────────────────────────────────────────" in
crates/vm/src/stdlib/sys/monitoring.rs (the section labeled "Event dispatch");
simply delete that line so the file adheres to the coding guideline prohibiting
decorative section separators and leave surrounding code and any real comments
intact.
- Around line 249-255: free_tool_id currently calls clear_tool_id (which locks
and unlocks vm.state.monitoring) and then re-locks to clear state.tool_names,
causing a TOCTOU race with concurrent use_tool_id; fix by extracting a helper
clear_tool_state(&mut MonitoringState, tool: usize) that performs both the
event/slot clearing and tool_names[tool]=None while a single lock is held, then
change clear_tool_id to acquire the lock and call clear_tool_state and change
free_tool_id to acquire the lock once and call clear_tool_state directly so both
operations happen under one lock.

---

Nitpick comments:
In `@crates/vm/src/frame.rs`:
- Around line 2106-2116: The code currently tests
vm.state.monitoring_events.load() != 0 for Instruction::Resume, ReturnValue, and
YieldValue which causes any subscribed event to trigger monitoring locks; change
these guards to test only the specific monitoring bits relevant to the events
being fired (use a bitmask check like vm.state.monitoring_events.load() &
(MONITOR_LINE|MONITOR_INSTRUCTION) != 0 or the exact constants for
RETURN/YIELD/RESUME as defined) before calling
fire_py_start/fire_py_resume/fire_py_return/fire_py_yield so locks are only
acquired when the matching event bits are set; update the checks in the
Instruction::Resume, ReturnValue, and YieldValue handlers (and the analogous
spots at the other mentioned ranges) to use the bitmask test rather than != 0.

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Line 473: Remove the decorative separator comment line "// ── Public dispatch
functions (called from frame.rs) ─────────────────" from monitoring.rs; either
delete it entirely or replace it with a concise, value-adding comment or a short
doc-comment that briefly states "Public dispatch functions (called from
frame.rs)" to comply with the guideline against decorative section separators
and keep the intent clear for the pub dispatch functions section.
- Around line 280-290: Replace the magic numeric literals 18, 8, and 9 with
named constants (e.g., BRANCH, BRANCH_LEFT, BRANCH_RIGHT) and use the same
derivation as the rest of the module so they stay in sync with EVENT_NAMES;
compute those constants from the event-bit/trailing-zeros logic used elsewhere
(derive the index/bit for "BRANCH", "BRANCH_LEFT", "BRANCH_RIGHT" the same way
the module derives event bits) and then use those constants in the
state.callbacks.insert/remove and the event_id comparison instead of raw numbers
(references: event_id, state.callbacks, tool, func, and the
EVENT_NAMES/trailing-zeros derivation).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 303-307: get_events currently returns the normalized mask (with
EVENT_C_RETURN_MASK/EVENT_C_RAISE stripped) because normalize_event_set is
applied before storing; change the monitoring data model to keep both the
normalized mask used for dispatch and the original raw mask used for API
round-trips (e.g., add a raw_global_events array or raw_events field alongside
global_events), update the code path that calls normalize_event_set (the writer
used by set_events) to store the normalized version in global_events and the
original unmodified mask in raw_global_events, and modify get_events (which
currently reads state.global_events[tool]) to return the stored original/raw
mask so callers see the exact bits they set.
- Around line 361-390: The all_events function only checks state.global_events
and therefore omits tool registrations present in state.local_events (registered
via set_local_events); update all_events to include local_events when
constructing each event's tools_mask by combining bits from
state.global_events[tool] and any state.local_events entries: when building
masks inside all_events, after computing event_bit and tools_mask from
state.global_events, iterate state.local_events (or otherwise aggregate per-tool
masks stored there) and OR in any bits that indicate the event is enabled
locally for that tool so EVENT_NAMES / UNGROUPED_EVENTS_COUNT and TOOL_LIMIT
usage remains the same and the resulting all_events dict reflects both global
and per-code-object local registrations.

---

Duplicate comments:
In `@crates/codegen/src/compile.rs`:
- Around line 5186-5191: The END_FOR/POP_ITER and implicit-return are being
attributed to iter.range() instead of the for-statement line; in compile_for
capture the for-statement's source range at the start (e.g. a variable like
stmt_range) and use that when calling set_source_range before emitting
Instruction::EndFor, Instruction::PopIter and the implicit return emission
instead of using iter.range(); make the same change for the second occurrence
around the other block (the one noted at 5197-5201) so both places use the saved
for-statement range rather than the iterable's range.

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Line 392: The decorative box-drawing comment line "// ── Event dispatch
──────────────────────────────────────────────────────" should be replaced with
a plain comment that follows guidelines (e.g., "// Event dispatch") to remove
the box-drawing characters; locate the separator in the monitoring.rs file and
update that comment so it no longer contains box-drawing characters or
decorative separators.

---

Nitpick comments:
In `@crates/codegen/src/ir.rs`:
- Around line 254-261: The code repeats std::collections::HashSet three times
when building non_nop_lines and kept_nop_lines; add a top-level import `use
std::collections::HashSet;` and then replace `std::collections::HashSet<_>` and
`std::collections::HashSet::new()` with `HashSet<_>` and `HashSet::new()`
respectively in the non_nop_lines and kept_nop_lines declarations so the block
reads using the imported type (affecting symbols non_nop_lines and
kept_nop_lines).

In `@crates/vm/src/stdlib/sys/monitoring.rs`:
- Around line 696-710: The pub function fire_stop_iteration is currently unused
(marked with #[allow(dead_code]); either remove it to avoid dead code or wire it
into the generator return path: call fire_stop_iteration(vm, code, offset,
exception) from the appropriate place in frame.rs where generators raise/return
via StopIteration (e.g., in the function that handles generator
completion/exception unwrapping), ensuring you pass the current VirtualMachine,
the PyCode for the frame, the bytecode offset, and the StopIteration exception
so EVENT_STOP_ITERATION is emitted at the correct moment.
- Around line 437-492: The fire() function currently releases
vm.state.monitoring then calls is_disable(...) inside the callback loop which
re-acquires the monitoring lock on every iteration; instead snapshot the
disabled set once before invoking callbacks and use that snapshot for
disable-checks to avoid repeated locking—capture let disabled_snapshot = { let s
= vm.state.monitoring.lock(); s.disabled.clone() } (or extract the relevant keys
for code_id/offset), then replace calls to is_disable(...) with a check against
disabled_snapshot (or change is_disable signature to accept the snapshot) while
keeping the existing logic that only allows disabling for event_id <
LOCAL_EVENTS_COUNT and preserving error creation via EVENT_NAMES.
- Around line 285-298: The code uses magic numeric event IDs (18, 8, 9) inside
register_callback when handling the composite BRANCH event; replace those
literals with the proper event constants or derived indices (e.g., use the
trailing-zero index of EVENT_BRANCH, EVENT_BRANCH_LEFT, and EVENT_BRANCH_RIGHT
or existing constants like EVENT_BRANCH_IDX/ EVENT_BRANCH_LEFT_IDX/
EVENT_BRANCH_RIGHT_IDX) when comparing event_id and when inserting/removing from
state.callbacks (references: the check "if event_id == 18", the inserts
"state.callbacks.insert((tool, 8), ...)" and "state.callbacks.insert((tool, 9),
...)" and the removals "state.callbacks.remove(&(tool, 8))"/"remove(&(tool,
9))"); update both the registration and clearing branches so they use the named
constants/derived indices instead of raw numbers.
- Line 494: Replace the decorative box-drawing comment line "// ── Public
dispatch functions (called from frame.rs) ─────────────────" with a plain
non-decorative comment (e.g. "// Public dispatch functions (called from
frame.rs)") or remove it entirely; locate this line in
crates/vm/src/stdlib/sys/monitoring.rs near the public dispatch functions and
update the comment so it no longer uses box-drawing characters.

In `@crates/vm/src/vm/interpreter.rs`:
- Line 128: The field initialization for monitoring_events uses the redundant
fully-qualified path crossbeam_utils::atomic::AtomicCell::new(0); replace it
with the already-imported AtomicCell::new(0) in the struct/initializer that
contains monitoring_events, keeping the behavior unchanged and relying on the
existing use statement for AtomicCell.