Move buffer slice OOB check from panic in wgpu to validation error in wgpu-core

[ErichDonGubler]

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

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[teoxoy]

The validation we are removing (which was recently added in #6432) applies in more cases than RenderPass::set_index_buffer. It also applied to:

• set_index_buffer on the render bundle encoder
• set_vertex_buffer on the render pass encoder & render bundle encoder
• map_async on the buffer

Looking at the spec as well, having it in these places seems correct.

[Wumpf]

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

[ErichDonGubler]

@teoxoy: Ah, right, I need to ensure that there's coverage for those methods, too. Will do that.

• Do it

[ErichDonGubler]

@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.