deno

35d3602a - fix(ext/webgpu): bounds-check + view-aware setBindGroup Uint32Array fast path (#33980)

fix(ext/webgpu): bounds-check + view-aware setBindGroup Uint32Array fast path (#33980) The `Uint32Array` fast path of `setBindGroup` in `compute_pass.rs`, `render_pass.rs` and `render_bundle.rs` had two related bugs (#33956): 1. `&data[start..(start + len)]` sliced unchecked. An out-of-range length panicked inside the op's `extern "C"` callback, and the panic crossed the C ABI as a process abort — six lines of JS could kill a running runtime. This PR adds an explicit bounds check that surfaces as a `GPUValidationError` (or a thrown JS error in the render-bundle path, which has no per-call `error_handler`) instead. 2. `uint_32.buffer(scope).data()` + `ab.byte_length() / 4` walked the backing `ArrayBuffer` and ignored the typed-array view's `byteOffset` and `length`. A `Uint32Array(buf, byteOffset > 0, …)` fed `wgpu_core` the wrong window with no error surfaced — silently incorrect rendering / compute results. The slice is now constructed from `byte_offset()` + `length()`. Adds a regression test (gated on `!isCIWithoutGPU`, like the other webgpu tests) that: - calls `setBindGroup(…, new Uint32Array(4), 0, 1_000_000)` against both a `ComputePass` (expects a validation error in the device error scope) and a `RenderBundleEncoder` (expects a thrown JS error), and - confirms a well-formed call still works. `deno fmt --check` and `deno lint` are clean on the changed files; the Rust changes will get their fmt/clippy from CI. Out of scope: a view-window behavioural test (`Uint32Array(buf, byteOffset=16, length=4)` producing the right wgpu binding) needs a full pipeline + buffer + dispatch + readback to observe; the reporter's standalone Rust harness in #33956 demonstrates the semantics of the fix. Credit to @hibrian827 for the diagnosis, three reproducers, and the suggested fix in the upstream report. Fixes #33956. @bartlomieju --- 🤖 Filed by `agor` (worker `work2-2`, bot `lunadogbot`). Tracking claim: bartlomieju/agent-job-board#24. (Note: `@lunadogbot` still needs CLA acceptance from the operator side, same as #33978.) --------- Signed-off-by: lunadogbot <lunadogbot@users.noreply.github.com> Co-authored-by: lunadogbot <lunadogbot@users.noreply.github.com> Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com> Co-authored-by: Leo Kettmeir <crowlkats@toaxl.com>