feat(core): add Global::create_bind_group_layout_error
#8650
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Some JS runtimes (like Firefox) want to control ID assignment for resources, unconditionally assigning them even when validation rules that has to happen in layers above
wgpu-coredetermine that resources are invalid before even talking towgpu-core. For these cases, we makewgpu_core::Global::create_*_errorAPIs, keepingwgpu-corethe source of truth for the presence and validity of objects.The motivation for this PR is that we are missing this for bind group layouts, specifically because of their entries. In WebGPU's WebIDL representation, such entries must have one and only one optional discriminant member specified, indicating which resource type is being used (link). In Rust, we use an
enum, and make invalid states unrepresentable. However, for JS, we must (and currently do not) affordwgpu-coreusers the ability to register invalid bind group layouts for this case, like we do for other APIs (see also the validation listed forGPUDevice.createBindGroupLayout).Add
wgpu_core::Global::create_bind_group_layout_error, which fixes this flaw.Testing
I don't see other
create_*_errorAPIs tested, and this is consistent with that. This is probably because this sort of API is not something that anything in-tree needs. I've been testing it in Firefox builds, and I believe it works well enough.Checklist
CHANGELOG.mdentry.