Skip to content

Conversation

@MarijnS95
Copy link
Collaborator

@MarijnS95 MarijnS95 commented Nov 15, 2025

Generating aliases will help ash with Vulkan-Headers updates without causing breaking changes when extensions and their global constants are promoted (from vendor to EXT to KHR to a Vulkan feature version) where the original constant suffix is renamed or removed while a fallback alias is added with the old name; which our generator was ignoring thus far.

One such example is MAX_GLOBAL_PRIORITY_SIZE_KHR which was stabilized in Vulkan 1.4 and renamed to MAX_GLOBAL_PRIORITY_SIZE; if we don't generate the old _KHR-suffixed constant as an alias to the stabilized constant that is technically a breaking change in ash's release cycle.

By generating these aliases we can remove one unnecessary hand-written define for SHADER_UNUSED_NV (which seems to have been specifically added to retain backwards compatibility).

(alt((
value(CType::U64, tag("ULL")),
value(CType::U32, tag("U")),
// success(CType::U32), // Only for `0x1234` hexadecimals without type-suffix
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was mainly "experimenting" with removing the Number and Hex variants from enum Constant because this code already handles both, but they'd end up weirdly formatted.

We have logic that doesn't append the type (ctype parsing does it by default) and interleaves the number with _.

EDIT: Though it wouldn't look out of order to just delete the 0x...u32 suffix.

.map(|constant| generate_constant(constant))
.collect();

constants_code.push(quote! { pub const SHADER_UNUSED_NV : u32 = SHADER_UNUSED_KHR;});
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was mainly thinking about autogenerating this - but these are impossible without knowing the type through some additional bookeeping and they feel a bit useless if it isn't for vendor suffixes that might be necessary for extension stabilization going forward.

@MarijnS95 MarijnS95 changed the title WIP: Handle enum-constants via vk-parse Generate aliases for global constants Nov 15, 2025
Generating aliases will help `ash` with `Vulkan-Headers` updates without
causing breaking changes when extensions and their global constants are
promoted (from vendor to `EXT` to `KHR` to a Vulkan feature version)
where the original constant suffix is renamed or removed while a
fallback **alias** is added with the old name; which our generator was
ignoring thus far.

One such example is `MAX_GLOBAL_PRIORITY_SIZE_KHR` which was stabilized
in Vulkan 1.4 and renamed to `MAX_GLOBAL_PRIORITY_SIZE`; if we don't
generate the old `_KHR`-suffixed constant as an alias to the stabilized
constant that is technically a breaking change in `ash`'s release cycle.

By generating these aliases we can remove one unnecessary hand-written
define for `SHADER_UNUSED_NV` (which seems to have been specifically
added to retain backwards compatibility).
@MarijnS95 MarijnS95 marked this pull request as ready for review November 16, 2025 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants