fix(daemon): bind `mods` in the mapped arm --- and withdraw b758c2e's build claim
The merge commitb758c2eDOES NOT COMPILE, and its message says "Workspace compiles clean, all targets, no warnings". That claim is WITHDRAWN. It was true of the tree I checked and false of the tree I committed. What happened: I staged the conflict resolution, ran cargo check, hit `cannot find value mods in this scope` at the mapped arm, edited src/daemon.rs to bind it, re-ran cargo check clean --- and then committed without re-staging that file. The verification and the commit were of different trees. This is the same defect class as gating one step of an edit-then-commit chain and leaving the next ungated: a commit that does not depend on the edit it claims. The fix itself is unchanged from what was verified. SS5b left `mods` in `..` on PanelPointerMapped; the mapped family carries the same modifiers, so leaving it there gives a v25 session the inverted Shift behaviour that parent 48 R-a fixed for v24. Verified at THIS commit, after staging: cargo check --workspace --all-targets, no errors and no warnings. Not amended away.b758c2estays in history with its false claim standing and this withdrawal attached, because erasing a bad record is worse than carrying a corrected one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
This commit is contained in:
parent
3cd7b8aa22
commit
cf78385b5e
|
|
@ -2629,6 +2629,12 @@ fn handle_dispatcher_event(
|
|||
coord,
|
||||
kind,
|
||||
mapping_generation,
|
||||
// Bound for the same reason as the legacy arm above,
|
||||
// and NOT optional here: the mapped family carries
|
||||
// the same modifiers, so leaving them in `..` would
|
||||
// give a v25 session the inverted Shift behaviour
|
||||
// that parent 48 R-a fixed for v24.
|
||||
mods,
|
||||
..
|
||||
} => {
|
||||
// §5b — the mapped family, in this order:
|
||||
|
|
|
|||
Loading…
Reference in New Issue