gfx-rs
Move buffer slice OOB check from panic in `wgpu` to validation error in `wgpu-core`
Connections
Exercised by webgpu:api,validation,encoding,cmds,render,setIndexBuffer:offset_and_size_oob:*, which was disovered to be failing in Firefox in this webgpu-backlog1 run on a Windows debug build in try:bed05e732fb557b6173872c508612399b6bc365e.
Description
wgpu implemented OOB checks on BufferSlice creation as a panic. However, it should be implemented as a validation check in wgpu-core. So fix it. 😀
Testing
- Exercised by
webgpu:api,validation,encoding,cmds,render,setIndexBuffer:offset_and_size_oob:*in Firefox.
Checklist
- [x] Run
cargo fmt. - [x] Run
taplo format. - [x] Run
cargo clippy. If applicable, add:- [x]
--target wasm32-unknown-unknown - [x]
--target wasm32-unknown-emscripten
- [x]
- [x] Run
cargo xtask testto run tests. - [x] Add change to
CHANGELOG.md. See simple instructions inside file.
To build upon that: slice specifically is a rust artifact and the validation done there is a rusty one just like slice on a vec validates.
Validating to consume a given BufferSlice in wgpu-core is another story.
On that note: the fields of BufferSlice should probably be just pub (which then again very much puts the spot light on the validation on wgpu-core which is needed for WebGPU compliance anyways). I remember another ticket somewhere that was struggling with this. BufferSlice itself is also just a rust artifact - in the WebGPU api this is handled with loose size & offset fields
@teoxoy: Ah, right, I need to ensure that there's coverage for those methods, too. Will do that.
- [ ] Do it
@Wumpf (CC @teoxoy): This is actually an interesting tension between typical Rust programming and the experience dictated by the WebGPU spec. The spec. specifies that this sort of error is a validation error; so, still safe, but we don't get a panic at the site of usage. I think this is for wgpu devs. to decide on, and honestly...maybe I should just punt the removal of the panicking for another issue/PR.