Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test extension header generation #462

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

eliemichel
Copy link
Collaborator

@eliemichel eliemichel commented Dec 9, 2024

This is a WIP of a test dedicated to the generation of extension header. The sample yaml file is mainly based on wgpu-native's wgpu.h file (from this branch) as I was thinking of handling two birds with one PR.

Hick-ups I could notice:

@kainino0x
Copy link
Collaborator

The sample yaml file is mainly based on wgpu-native's wgpu.h file (from this branch) as I was thinking of handling two birds with one PR.

It's nice to test a real case but it would be very useful to have a test file that has just one or two of every possible type of extension in it, as that would make it easy to review that the generator is producing the right thing.
Probably not all of these are possible now, but whichever of these are possible should be tested (I'm sure you already hit many or all of these but I haven't checked yet, sorry):

  • New constant
  • New typedef
  • New enum with new value
  • New value on old enum
  • New bitflags type with new flag
  • New flag on old bitflags type
  • New struct
  • New extension struct to new base struct
  • New extension struct to old base struct
  • New callback type (and a method that uses it)
  • New function
  • New object with new method
  • New method on old object

@eliemichel
Copy link
Collaborator Author

It's nice to test a real case but it would be very useful to have a test file that has just one or two of every possible type of extension in it, as that would make it easy to review

Sure! Sorry for throwing all that here, I'll strip it down to a more strategic test prior to marking as non-draft!

@kainino0x
Copy link
Collaborator

No problem, just pre-review thoughts (about how I'm going to review it) :)

@kainino0x kainino0x added the non-breaking Does not require a breaking change (that would block V1.0) label Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
non-breaking Does not require a breaking change (that would block V1.0)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants