Skip to content

Conversation

@Exanite
Copy link
Contributor

@Exanite Exanite commented Nov 24, 2025

Summary of the PR

This PR focuses on implementing the improvements identified in #2457.
Depending on the scope of the tasks, some of these tasks may be pushed to another PR.

Related issues, Discord discussions, or proposals

Previous Vulkan PR (initial bindings generation): #2457
Discord thread: https://discord.com/channels/521092042781229087/1376331581198827520/1442651368207941643

Further Comments

Tasks not part of this PR

These are the tasks from my previous PR. These have been sorted and trimmed down to ensure that this PR remains focused. These may be added to this PR.

If you want to see the original, unmodified set of tasks, please see #2457.

  • Apply BoolType transformation to VkBool32 in structs. They currently are only handled for functions.
  • Add default field values to structs where it makes sense (eg: SType)
  • Ensure SupportedApiProfiles attributes are correct
    • Properly resolve API profiles for Flags/FlagBits types

Future PRs

  • Update Curin's branch to use my new LocationTransformation code. The new renamer should be replaced with this. See the NameUtils.cs and Renamer.cs files on Curin's branch. Renamer.cs should be removed. NameUtils.cs should have the methods updated to use my LocationTransformation code instead (this should show up as a merge conflict).
    • PR opened and ready for review/merge
    • PR merged
    • Old renamer code removed
  • Reimplement the struct chaining API

Name prettification

New Tasks

  • Consider opening a ClangSharp PR to fix issue with SDL_MAX_SINT64 generation on Linux
  • Consider splitting ExtractNestedTyping and TransformHandles into a new set of Extract- mods.
    • This this mainly for maintainability for ExtractNestedTyping, but for TransformHandles, it is useful for AddApiProfiles to be executed after all types are extracted, but not yet transformed.
    • Alternatively, make AddApiProfiles strictly work off of NativeName attributes.

Current Todos

Improve prefix and suffix handling during prettification.

  • Add NativeName attribute
  • Ensure NativeName attribute is added by all mods that generate new types/members
    • Technically not strictly required, but nice from a API consistency standpoint.
    • MixKhronosData
      • Enum members
      • Enum declarations
        • Vulkan (uses FlagBits version of enum names since it is more helpful when googling)
        • Other Khronos APIs (some APIs don't have actual enums)
    • ExtractNestedTyping
      • Function pointers
      • Others?
    • TransformHandles
  • Properly trim prefixed/suffixed names, such as PFNVkDebugUtilsMessengerCallbackEXT and BufferTHandle
    • PFNVkDebugUtilsMessengerCallbackEXT prefix
    • PFNVkDebugUtilsMessengerCallbackDelegateEXT suffix
    • AccelerationStructureHandleKHR suffix
    • Extract vendor extensions from names and store into NameSuffix attributes.
    • Revert "hacky" THandle fix.
  • Consider renaming handle types as HandleEXT instead of EXTHandle for readability.
    • This is fairly doable. The above todos track this.

Completed Todos

(Newest groups at the top. Order within a group is chronological.)

Fix bugs from original PR

  • Enums containing negative values should not have an unsigned backing type.

Handle struct improvements

  • Handle structs don't have an easy way of being constructed (field is readonly and no constructor).

Things to watch for during review

I regenerated all of the bindings, but on Linux. I'll probably commit the Windows version before undrafting for consistency. Note that I only have access to Linux/Windows so when I say only on Linux/etc, I mean on Linux and not on Windows.

  • SDL: VaListTagHandle is a handle struct that only generates on Linux. This struct also breaks global prefix determination, so I added SDL as a global prefix hint for PrettifyNames in the generator config.
  • OpenAL: ContextErrorCode was replaced with ErrorCode. This also happened in the previous PR, but I didn't commit it. This was not the case in the OpenAL PR. This happens on both Linux and Windows. Maybe this is a Mac specific inconsistency?

This looks like it's from some sort of built-in renamer.
Don't think we'll ever use this since we have a custom renamer.
Not sure why these were not being coerced when the Vulkan PR was merged, but they started getting coerced in this PR.
This technically is a good thing since it means the coerce backing types code is now working as previously intended.
However, the previously intended implementation missed an edge case, which this commit fixes.
This is because the structs were impossible to reasonably construct before.
Technically this is from my update PR into Curin's branch (curin#101), but is effectively the same as backporting the changes from Curin's branch.
Exact commit that I copied the changes from: 0cc698a
VaListTagHandle is an extra handle struct that seems to generate on Linux (and not on Windows) and breaks global prefix determination.
OpenAL: ContextErrorCode seems to always be replaced with ErrorCode, even on Windows. Not sure why. This also happened during the last PR, but I didn't commit it.
Honestly, what I wrote is a complete guess, I'll likely revisit these once I understand them more.
The functionality this method contains seems heavily duplicated.
I will likely update existing code in a later commit.
SDL is still erroring:

Sdl.gen.cs(60143,45): Error CS0266 : Cannot implicitly convert type 'long' to 'nint'. An explicit conversion exists (are you missing a cast?)
Sdl.gen.cs(60143,35): Error CS0133 : The expression being assigned to 'Sdl.MaxSint64' must be constant

[NativeTypeName("#define SDL_MAX_SINT64 SDL_SINT64_C(0x7FFFFFFFFFFFFFFF)")]
public const nint MaxSint64 = unchecked(0x7FFFFFFFFFFFFFFF);

At first glance, this might be a ClangSharp issue with how these defines are generated on Linux.
@Exanite Exanite force-pushed the feature/vulkan-bindings-3.0-improvements branch from f991aaa to b4cdd0e Compare November 27, 2025 02:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

1 participant