Parse and provide bitwidth attribute on <enums> element #17
Conversation
This change prepares for future additions in vk_parse fields ([1]) by converting over the enum generation path from vkxml. Most of the conversion is easy by repurposing the existing `EnumSpec` parsing logic from extension constants for all enumeration variants, with slight modifications to not bail when `extends` is not set which is specific to extension constants. As an (unintended) added bonus this unification of the `EnumSpec` codepath allows aliases (for backwards-compatible names) to be generated as discussed earlier in [2]. [1]: krolli/vk-parse#17 [2]: ash-rs#384 (comment)
Since Vulkan-Headers v1.2.170 with VK_KHR_synchronization2 there are now bitmasks/enums using 64-bits instead of the default 32. vk-parse has been updated [1] to convey this info though the typedefs for these enumerations could be parsed as well. [1]: krolli/vk-parse#17
This change prepares for future additions in vk_parse fields ([1]) by converting over the enum generation path from vkxml. Most of the conversion is easy by repurposing the existing `EnumSpec` parsing logic from extension constants for all enumeration variants, with slight modifications to not bail when `extends` is not set which is specific to extension constants. As an (unintended) added bonus this unification of the `EnumSpec` codepath allows aliases (for backwards-compatible names) to be generated as discussed earlier in [2]. [1]: krolli/vk-parse#17 [2]: #384 (comment)
Since Vulkan-Headers v1.2.170 with VK_KHR_synchronization2 there are now bitmasks/enums using 64-bits instead of the default 32. vk-parse has been updated [1] to convey this info though the typedefs for these enumerations could be parsed as well. [1]: krolli/vk-parse#17
This change prepares for future additions in vk_parse fields ([1]) by converting over the enum generation path from vkxml. Most of the conversion is easy by repurposing the existing `EnumSpec` parsing logic from extension constants for all enumeration variants, with slight modifications to not bail when `extends` is not set which is specific to extension constants. As an (unintended) added bonus this unification of the `EnumSpec` codepath allows aliases (for backwards-compatible names) to be generated as discussed earlier in [2]. [1]: krolli/vk-parse#17 [2]: ash-rs#384 (comment)
* generator: Generate enums from vk_parse representation This change prepares for future additions in vk_parse fields ([1]) by converting over the enum generation path from vkxml. Most of the conversion is easy by repurposing the existing `EnumSpec` parsing logic from extension constants for all enumeration variants, with slight modifications to not bail when `extends` is not set which is specific to extension constants. As an (unintended) added bonus this unification of the `EnumSpec` codepath allows aliases (for backwards-compatible names) to be generated as discussed earlier in [2]. [1]: krolli/vk-parse#17 [2]: #384 (comment) * generator: Turn "backwards"-mentioning docs into deprecation notices All constant aliases for misspelled items (missing `_BIT` andsoforth) contain the text "backwards compatibility" or "Backwards-compatible alias". * generator: Drop aliases whose name becomes identical after de-mangling * generator: Remove aliases from const_debugs These already have a match against the name they're aliasing, and some of the aliases are "deprecated" (since they're just typo fixups for backwards compatibility).
Since Vulkan-Headers v1.2.170 with VK_KHR_synchronization2 there are now bitmasks/enums using 64-bits instead of the default 32. vk-parse has been updated [1] to convey this info though the typedefs for these enumerations could be parsed as well. [1]: krolli/vk-parse#17
Since Vulkan-Headers v1.2.170 with VK_KHR_synchronization2 there are now bitmasks/enums using 64-bits instead of the default 32. vk-parse has been updated [1] to convey this info though the typedefs for these enumerations could be parsed as well. [1]: krolli/vk-parse#17
MarijnS95
force-pushed
the
enums-bitwidth
branch
from
873860c to
7fd0caa
Compare
vk.xml file is weird combination of structured XML and tagged C code. Structured parts could definitely go through serde, but I'm not sure about tagged C code. Currently content of these elements is collected and later parsed (in a very hacky way), but originally this was done together. I think there was some discussion within Khronos about having vk.xml format structured with defined schema, but they chose against it as it made things too rigid and hard to work with. Even if it might be possible to change the parsing code to serde right now, there is no guarantee that they don't introduce something hard to deal with in the future. I prefer to stick with SAX parser since it provides more flexibility and drags in fewer dependencies. Back to the PR, addition of |
|
Right, I was explained earlier that serde is not (or does not appear to be) expressive enough to deal with this heavy intermixing of XML elements and text nodes, which pretty much define the whole Vulkan format (it is effectively a header with some heavy XML annotation interspersed).
As mentioned in #18 outdated crates actually cause issues, so I'd suggest either dropping |
|
I would like to discuss the |
This attribute specifies - together with a typedef to VkFlags(64) - the size of an enum. VK_KHR_synchronization2 introduces larger bitflags/bitmasks with more than 32 bits in use. These bitmasks have bitwidth set to 64, while the default for enums is assumed to be 32 bit.
MarijnS95
force-pushed
the
enums-bitwidth
branch
from
7fd0caa to
b536924
Compare
This attribute specifies - together with a typedef to VkFlags(64) - the size of an enum. VK_KHR_synchronization2 introduces larger
bitflags/bitmasks with more than 32 bits in use. These bitmasks have bitwidth set to 64, while the default for enums is assumed to be 32 bit.
Future tasks
vk.xmls (.172) can be tested in the CI.If I may ask: Why isn't this crate deserializing to structures directly with Serde, followed by optional conversion and error checking? The manual approach with
match_attributes!is pretty verbose. Or was that not possible/not expressive enough back in the day?