style: run prettier --write .

Author: ErichDonGubler

.claude/skills/cts-triage/SKILL.md

@@ -48,6 +48,7 @@ cargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep -E "(
 ```
 
 Track the pass rate for each subcategory. This helps you identify:
+
 - What's already working (don't break it!)
 - Where the failures are concentrated
 - Which issues affect multiple categories
@@ -61,6 +62,7 @@ cargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep "\[fa
 ```
 
 Look for patterns:
+
 - **Format-specific failures**: May indicate missing format capability checks
 - **Parameter-specific failures**: Validation missing for specific parameter combinations
 
@@ -73,6 +75,7 @@ cargo xtask cts 'webgpu:api,validation,category:subcategory:specific_test' 2>&1
 ```
 
 Look for:
+
 - **"EXPECTATION FAILED: DID NOT REJECT"**: wgpu is accepting invalid input (validation gap)
 - **"Validation succeeded unexpectedly"**: Similar to above
 - **"Unexpected validation error occurred"**: wgpu is rejecting valid input
@@ -87,6 +90,7 @@ grep -A 40 "test_name" cts/src/webgpu/api/validation/path/file.spec.ts
 ```
 
 The test source shows:
+
 - What configurations are being tested
 - What the expected behavior is (pass/fail)
 - The validation rules from the WebGPU spec
@@ -97,21 +101,25 @@ The test source shows:
 Group failures into categories:
 
 **High Priority - Validation Gaps:**
+
 - wgpu accepts invalid configurations that should fail
 - Security or correctness implications
 - Example: Accepting wrong texture formats, missing aspect checks
 
 **Medium Priority - Spec Compliance:**
+
 - Edge cases not handled correctly
 - Optional field validation issues
 - Example: depthCompare optional field handling
 
 **Low Priority - Minor Gaps:**
+
 - Less common scenarios
 - Limited real-world impact
 - Example: Depth bias with non-triangle topologies
 
 **Known Issues - Skip:**
+
 - Known failure patterns (documented in AGENTS.md)
 - Track count but don't try to fix
 
@@ -120,6 +128,7 @@ Group failures into categories:
 For validation gaps, find where validation should happen:
 
 1. **Search for existing validation:**
+
    ```bash
    grep -n "relevant_keyword" wgpu-core/src/device/resource.rs
    ```
@@ -130,6 +139,7 @@ For validation gaps, find where validation should happen:
    - Look for existing validation patterns you can follow
 
 3. **Check for helper functions:**
+
    ```bash
    grep "fn is_" wgpu-types/src/texture/format.rs
    ```
@@ -162,25 +172,31 @@ Do not write information about changes you have made to the triage document. Onl
 **Overall Status:** XP/YF/ZS (%/%/%)
 
 ## Passing Sub-suites ✅
+
 [List sub-suites that have no failures (all pass or skip)]
 
 ## Remaining Issues ⚠️
+
 [List sub-suites that have failures and if it can be stated concisely, a summary of the issue]
 
 ## Issue Detail
+
 [List detail of any investigation into failures. Do not go into detail about passed suites, just list the failures.]
 
 ### 1. title, e.g. a distinguishing word from the test selector
+
 **Test selector:** `webgpu:api,validation,render_pipeline,depth_stencil_state:format:*`
 **What it tests:** [Description]
 **Example failure:**
 [a selector for a single failing test, e.g.:]
+
 ```
 webgpu:api,validation,render_pipeline,depth_stencil_state:depthCompare_optional:isAsync=false;format="stencil8"
 ```
 
 **Error:**
 [error message from the failing tests, e.g.:]
+
 ```
 Unexpected validation error occurred: Depth/stencil state is invalid:
 Format Stencil8 does not have a depth aspect, but depth test/write is enabled
@@ -194,6 +210,7 @@ The validation is triggering incorrectly. When `depthCompare` is undefined/missi
 [Your proposed fix. Again, do not speculate. Only state the fix if it is obvious from the root cause analysis, or if you have done specific investigation into how to fix it.]
 
 ### 2. title
+
 [repeat as needed for additional issues]
 ````
 
@@ -202,6 +219,7 @@ The validation is triggering incorrectly. When `depthCompare` is undefined/missi
 For fixed tests that are now passing, add them to `cts_runner/test.lst`:
 
 1. **Use wildcards** to minimize lines:
+
    ```
    webgpu:api,validation,category:subcategory:isAsync=false;*
    ```
@@ -237,26 +255,31 @@ noted here with "do not attempt to fix", then stop and ask the user before
 attempting to fix.
 
 **Pattern: Format-specific failures**
+
 - Check if format validation is missing
 - Look for `is_depth_stencil_format()`, `is_color_format()` etc.
 - May need to add format capability checks
 
 **Pattern: Aspect-related failures**
+
 - Check if code validates format aspects (DEPTH, STENCIL, COLOR)
 - Use `hal::FormatAspects::from(format)` to check
 - Validate operations match available aspects
 
 **Pattern: Optional field failures**
+
 - May be WebGPU optional field semantics issue
 - Check if undefined in JS becomes a default value in Rust
 - May need to distinguish "not set" from "set to default"
 
 **Pattern: Atomics accepted incorrectly**
+
 - Naga allows referencing an atomic directly in an expression
 - Should only allow accessing via `atomicLoad`, `atomicStore`, etc.
 - Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/5474.
 
 **Pattern: Error reporting for destroyed resources**
+
 - Tests that check for validation errors when a destroyed resource is used. `wgpu` often reports these errors later than WebGPU requires, causing the tests to fail.
 - `wgpu` may report these errors earlier than it should, causing the test to fail with an unexpected validation error.
 - Look for:

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,10 +1,9 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: ''
+title: ""
 labels: bug
-assignees: ''
-
+assignees: ""
 ---
 
 <!-- Thank you for filing this! Please read the [debugging tips](https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications).

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,10 +1,9 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
+title: ""
 labels: enhancement
-assignees: ''
-
+assignees: ""
 ---
 
 **Is your feature request related to a problem? Please describe.**

.github/ISSUE_TEMPLATE/other.md

@@ -1,7 +1,7 @@
 ---
 name: Other
 about: Strange things you want to tell us
-title: ''
+title: ""
 labels: question
-assignees: ''
+assignees: ""
 ---

.github/workflows/ci.yml

@@ -760,7 +760,7 @@ jobs:
 
       # Miri is *only* available on nightly.
       - name: Install nightly toolchain
-      
+
         run: |
           rustup toolchain install nightly --no-self-update --profile=minimal --component miri
           rustup override set nightly
@@ -781,7 +781,6 @@ jobs:
           # Consider expanding it to include some API tests with the noop backend.
           cargo miri test --package=wgpu --no-default-features -- write_only
 
-
   fmt:
     # runtime is normally 15 seconds
     timeout-minutes: 2

AGENTS.md

@@ -1,6 +1,7 @@
 # Global instructions
 
 ## Code Style
+
 - Limit the amount of comments you put in the code to a strict minimum. You should almost never add comments, except sometimes on non-trivial code, function definitions if the arguments aren't self-explanatory, and class definitions and their members.
 - Do not use emoji.
 
@@ -91,30 +92,29 @@ See `docs/big-picture.png` for an overview of the system.
 
 The major components are:
 
-* `wgpu-hal` implements a backend for each supported graphics API (Vulkan, DX12, Metal, GLES).
+- `wgpu-hal` implements a backend for each supported graphics API (Vulkan, DX12, Metal, GLES).
 
-* `wgpu-core` implements the WebGPU API, including resource management and validation.
+- `wgpu-core` implements the WebGPU API, including resource management and validation.
   It calls the platform graphics APIs via `wgpu-hal`, and uses `naga` for shader translation.
 
-* `wgpu` is the native Rust API. In addition to providing bindings to `wgpu-core`, the `wgpu`
+- `wgpu` is the native Rust API. In addition to providing bindings to `wgpu-core`, the `wgpu`
   crate can also be compiled to WASM and built against the "WebGPU" backend, where it uses
   whatever WebGPU implementation is provided by the WASM environment. `wgpu` is not used
   by Deno and Firefox.
 
-* `naga` is the shader translator. It reads shaders in WGSL, GLSL, or SPIR-V,
+- `naga` is the shader translator. It reads shaders in WGSL, GLSL, or SPIR-V,
   translates to Naga IR, and then writes shaders in GLSL, HLSL, MSL (Metal Shading Language), SPIR-V, or WGSL.
   It is responsible for validating that WGSL shaders are valid according to the WGSL language specification.
 
-* `wgpu-types` contains some type definitions that are applicable both to `wgpu-core` and to
+- `wgpu-types` contains some type definitions that are applicable both to `wgpu-core` and to
   the `wgpu` "WebGPU" backend.
 
-* `deno_webgpu` contains WebGPU bindings for the Deno Javascript runtime.
+- `deno_webgpu` contains WebGPU bindings for the Deno Javascript runtime.
   We also use Deno as a test environment for running the WebGPU CTS.
   Only make a change in the Deno bindings if you are sure that the issue
   doesn't apply to other clients (Firefox or `wgpu` Rust API). If it does
   apply to other clients, the issue should probably be fixed in `wgpu-core`.
 
-
 For a more detailed discussion of the `wgpu` architecture, refer to
 <https://github.com/gfx-rs/wgpu/wiki/Architecture>.
 
@@ -173,6 +173,7 @@ This is stuff that Claude wrote for itself. It can probably be improved.
    - Verify constant evaluation by checking the output file
 
 **Running Tests:**
+
 ```bash
 # Unit tests only
 cargo test -p naga --lib

CODE_OF_CONDUCT.md

@@ -14,14 +14,14 @@ In this community we strive to go the extra step to look out for each other. Don
 
 And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could’ve communicated better — remember that it’s your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust.
 
-* Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
-* Please be kind and courteous. There’s no need to be mean or rude.
-* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
-* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
-* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term “harassment” as including the definition in the [Citizen Code of Conduct](https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.
-* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact the maintainers immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.
-* Do not make casual mention of slavery or indentured servitude and/or false comparisons of one's occupation or situation to slavery. Please consider using or asking about alternate terminology when referring to such metaphors in technology.
-* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
+- Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
+- Please be kind and courteous. There’s no need to be mean or rude.
+- Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
+- Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
+- We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term “harassment” as including the definition in the [Citizen Code of Conduct](https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.
+- Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact the maintainers immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.
+- Do not make casual mention of slavery or indentured servitude and/or false comparisons of one's occupation or situation to slavery. Please consider using or asking about alternate terminology when referring to such metaphors in technology.
+- Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
 
 ## Moderation
 

CONTRIBUTING.md

@@ -7,6 +7,7 @@ contribute. If you are unfamiliar with the wgpu project, we recommend you read
 [`GOVERNANCE.md`] for an overview of its goals, and how it's governed.
 
 ## Table of Contents
+
 - [Documentation Overview](#documentation-overview)
 - [Talking to other humans in the wgpu project](#talking-to-other-humans-in-the-wgpu-project)
 - ["What can I work on?" as a new contributor](#what-can-i-work-on-as-a-new-contributor)
@@ -40,7 +41,6 @@ The wgpu project has multiple official platforms for community engagement:
 - The Matrix channel [`wgpu:matrix.org`](https://matrix.to/#/#wgpu:matrix.org)
   is dedicated to informal chat about contributions the project. It is
   particularly useful for:
-
   - Saying hello, and introducing yourself.
   - Validating contributions (i.e., determining if they'll be accepted,
     ensuring your approach is correct, making sure you aren't wasting effort,
@@ -58,7 +58,6 @@ The wgpu project has multiple official platforms for community engagement:
 
 - [GitHub issues] are used to discuss open development questions and track work
   the community intends to complete; this might include:
-
   - Work that needs resolution via pull requests (see below)
     - Bug reports
     - Feature requests
@@ -77,12 +76,11 @@ The wgpu project has multiple official platforms for community engagement:
   happen on Google Meet and happen on Wednesday at 11:00 US Eastern Standard
   Time and last approximately an hour. Remember to obey the
   [`CODE_OF_CONDUCT.md`] in the meeting.
-
   - [Meeting Notes]
   - [Meeting Link]
+
 - [GitHub discussions]: TODO: Experimentally used by some enthusiastic members
   of our community. Not supported officially.
-  
 
 [GitHub discussions]: https://github.com/gfx-rs/wgpu/discussions
 [GitHub issues]: https://github.com/gfx-rs/wgpu/issues
@@ -178,7 +176,7 @@ understand it as a positive change to the codebase.
 
 Using LLMs and AIs to generate code that is part of a contribution is allowed.
 However, the author submitting the PR must fully adhere to [Change Ownership](#change-ownership) rules.
-The author is responsible for the code, regardless of how it was created. 
+The author is responsible for the code, regardless of how it was created.
 Do not use "LLM generated" as a justification for low quality code.
 
 #### Designing new features
@@ -229,12 +227,12 @@ These problems are serious enough that maintainers may choose to
 reject large, complex pull requests, regardless of the value of the
 feature or the technical merit of the code.
 
-The problem isn't really the *size* of the pull request: a simple
+The problem isn't really the _size_ of the pull request: a simple
 rename, with no changes to functionality, might touch hundreds of
 files, but be easy to review. Or, a change to naga might affect dozens
 of snapshot test output files, without being hard to understand.
 
-Rather, the problem is the *complexity* of the pull request: how many
+Rather, the problem is the _complexity_ of the pull request: how many
 moving pieces does the reviewer need to assess at once? In our
 experience, almost every large change can be pared down by separating
 out:
@@ -245,7 +243,6 @@ out:
 - Helpers and utilities that can be used elsewhere in the code base,
   even if they don't show their full value until the whole thing is
   merged.
-  
 - Renames and code motion with no semantic effect, like changes to
   types or behavior. When putting these in a separate pull request
   would be awkward, they should at least be segregated into their own