generate header from yaml spec

[rajveermalviya]

Add a custom yaml spec as discussed in #207, the details about the format can be found in the schema.json.

To test the generator:

1. First make sure you have Go installed.
2. Make some change in webgpu.yml
3. Run make gen

The generator can also be used to generate a separate implementation specific C header along side webgpu.h. The steps to do that is:

1. Create a new yaml file, for example wgpu.yml
2. Populate it with minimal required fields, refer to schema.json and this example.
3. Run go run ./gen -schema schema.json -yaml wgpu.yml -header wgpu.h

Another option is to generate a single header from multiple yaml specs, which is also included but disabled currently.
I prefer separate headers because that's what wgpu-native uses currently.

[ben-clayton]

Go / template readability LGTM. Thank you for all the changes.
Review still needed from project maintainers.

[kainino0x]

Sorry for the delay, I've been having a hard time catching up with work. Thank you Ben for the Go readability review!

One high level comment - I'd like to have a blocking GitHub Actions check that the generated output is up-to-date. This shouldn't be too complicated, just run the generator and then check that the git repository is clean.

[kainino0x]

(Oh, and - since we are generating files already - I wonder if we could also generate and check in a JSON version of the YAML file, for easy ingestion by other projects? But let's save this for a future PR.)

[kainino0x]

I don't have much to say about the Go code. I don't know Go, but it seems good, and if it works, it works :) Looking at the schema, it looks really great!

The changes to webgpu.h look really easy to reproduce in Dawn (except the callback definition order will require a little work), so we can stay in sync until we start using this generator in Dawn (hopefully).

I added some comments for future work, but let's probably do those in another PR.
Just a few little things I'd like to do before landing this, but they're not critical.

[kainino0x]

Plan for this commented-out code?

[rajveermalviya]

removed for now, plan is to add it back later (for finding invalid duplicates across multiple yaml specs).

[kainino0x]

(Can be future work)
Maybe we could use regex patterns to validate these a little more?
https://json-schema.org/understanding-json-schema/reference/string#regexp

These would get peppered all over the place so we'd probably want to link to the definition by reference:
https://stackoverflow.com/a/62585173/1268131

[kainino0x]

Regex patterns are useful here too: ^(0x[0-9A-F]{4}|0|[1-9][0-9]{0,4})$ or something like that

Though perhaps better - since we're using YAML already which supports hexadecimal numbers - could we just accept integers here instead? With range validation:
https://json-schema.org/understanding-json-schema/reference/numeric#range
(Can also be future work)

[kainino0x]

(Can be future work)
For the INIT macros (and generating C++ bindings), some optional members will need to know what their default value is (like WGPU_DEPTH_SLICE_UNDEFINED). Probably we can just put that here, though an alternative could be to move that information into the "type system" and give the depthSlice member a special type that knows its default.

[rajveermalviya]

default values are planned - In-order to keep this initial PR minimal, a future PR which includes both the header generation and default values populated in the yaml at once would be better.

[kainino0x]

LGTM! Nice reduction on the schema, thanks for digging deeper into what we could do with ref.

[kainino0x]

I've left the future work comments "unresolved" as a reference.

[kainino0x]

I'll go ahead and merge since webgpu.h changes are minimal - in Dawn we can hopefully catch up soon so the sync process won't be made harder.