Current progress

(Will update this as I work)

Bindings now compile!!!

See bottom of PR for current progress since I'm now actively tracking todos here.

Summary of the PR

This PR primarily adds Vulkan bindings.

Summary of important decisions/changes:

• Add aremap-stdint.rsp file specific to Vulkan bindings generation tofixuint64_t mapped tonuint on Linux (butulong on Windows) ClangSharp#574
• Change MSBuildModContext to only remove project documents that are part of the output directory. This is to ensure that the global usings files are not removed.
  • Seehttps://discord.com/channels/521092042781229087/1376331581198827520/1381026216466845716
• Change ModCSharpSyntaxRewriter to exclude global usings when injecting using statements.
  • This is in response to the MSBuildModContext change.
  • Seehttps://discord.com/channels/521092042781229087/1376331581198827520/1391155465328529491
• Add missing handle type discovery and empty struct generation for missing handle types to ExtractNestedTyping
• Rewrite TransformHandles to only transform existing empty structs. It will no longer generate new empty structs.
• Add theSilk.NET.SilkTouch.Mods.LocationTransformation namespace. This contains code that allows a set of transformations to be applied to the locations returned by SymbolFinder.FindReferencesAsync. This is currently used for renaming and for pointer dimension reduction (eg: replacingType* withType).

Related issues, Discord discussions, or proposals

Initial Discord discussion:https://discord.com/channels/521092042781229087/587346162802229298/1375224188129906778

Discord thread:https://discord.com/channels/521092042781229087/1376331581198827520/1376623544875880589

Further Comments

Things to know

The change to ExtractNestedTyping and TransformHandles is abreaking change.
Existing binding generator configurations need to have their configurations updated.

Todos

Uncategorized

• Implement Vulkan vtable function pointer management
  • Not exactly sure what I need to do here yet. I'll do some research.
• (Fixed-ish; see below task) I don't think I enabled generation of non-static vtables. All methods are static right now.
  • (Discuss) I enabled the generation of the StaticWrapper vtable, but I'm not sure if this is what we want for Vulkan.

Before undrafting PR

• Self code review and make sure all important changes/decisions are documented in the PR summary.
• Consider updating configs for other bindings because my changes affects them.
  • ExtractNestedTyping and TransformHandles
  • PrettifyNames mod order
• Update my LocationTransformer code to work with changes made in curin's PR:0cc49b8#diff-4d93e56d6d07a37ac3577a7fa2dfd0f0649e9ac07912045809c723351c9be56c
  • Curin is now aware of this code and is working with it

Future PRs

• Change naming convention to not capitalize acronyms
  • See:https://discord.com/channels/521092042781229087/1376331581198827520/1395097379329282089
• Structs don't have constructors unlike Silk 2. I don't know if this was an intentional change or if this functionality simply hasn't been properly implemented yet.
  • Conclusion: The constructors were for setting default field values, but we can set default field values directly now.
  • Add default field values to structs where it makes sense
• Ensure attributes are correct
  • SupportedApiProfiles
  • NativeTypeName
• TheVk inPFNVkDebugUtilsMessengerCallbackEXT is not trimmed properly
  • This seems similar to the issue we had with TransformHandles. We need to prettify/trim first, then add PFN- to the front.
  • I'll fix this in a separate PR that implements "middleware"-like mod execution. Mods will be executed in two phases: once in forward order (as they are now), and another time in reverse order. This allows mods likeExtractNestedTyping to first generate the pointer function struct in the forward pass, have the name be prettified, then add thePFN- prefix in the reverse pass.
• FixStdVideoEncodeH264SliceHeaderFlags property names. They currently aren't getting prettified.
  • I'm worried about conflicting with Curin's PR here. Curin also makes some (light) changes to the PrettifyNames code and surrounding code. I'm likely safe to make the changes, but I'd rather do this in a separate PR.

In progress

• Fix generation of bitshifts
  • Eg:(((uint)(0)) << 29U) | (((uint)(1)) << 22U) | (((uint)(0)) << 12U) | ((uint)(0))
  • I'm fixing this in ClangSharp:ClangSharpPInvokeGenerator does not handle unsigned int bitshifts correctly ClangSharp#611

Done

Bitfield structs

• Consider transforming bitfield structs into enums where possible
  • Eg:StdVideoEncodeH264SliceHeaderFlags
  • Decision: We're keeping these as bitfield structs.

Bools

• SamplerCreateInfo.UnnormalizedCoordinates,SamplerCreateInfo.CompareEnable, etc usesuint instead of abool-like type.
  • (Discuss) Is this related to the MaybeBool type? I haven't looked at the rest of Silk 3 yet. If so, then this might be something that can be fixed separately from the PR.
  • The SDL bindings already use MaybeBool, so the functionality already exists. I'll look into how to use it for Vulkan.

Deprecated aliases

• (Discuss)VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT (alias ofVK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT),VK_KHR_MAINTENANCE1_SPEC_VERSION, etc are deprecated aliases that cause compilation issues due to name conflicts. These are currently manually excluded.
  • These are marked with thedeprecated="aliased" attribute in the XML spec
  • Automate the list of type exclusions
  • Decision: I'm going to implement this because these names tend to cause conflicts during name prettification and because there is always an obvious alternative available. This can lead to more upstream breakages, but fixing these errors are trivial. Removing these also reduces confusion about which one to use.

MaxEnum members

• MaxEnum enum member removal also needs to considerINVALID members (Vulkan Video)
  • This is trickier because we can't just indiscriminately remove theINVALID members when the name contains the string
• MaxEnum member removal skips over enums not read from the XML
  • This includes both the Vulkan Video enums (there is a XML spec, but we don't read it) and the enums that are empty
    in the Vulkan XML spec (the XML spec is out of date/out of sync)
  • This also impacts the adding of[Flags] attributes.

I ended up making it so that theTransformEnums mod handlesMaxEnum removal instead ofMixKhronosData. This is because the max enum value pattern applies to C as a whole, rather than just Vulkan or Khronos.

• (Discuss) MixKhronosData ignores empty enums/groups from the XML. Would it be better to generate empty enums for these instead of completely ignoring them?
  • This is due to the group data only being initialized if there is at least one group member (search fordata.Groups[group] = data.Groups.TryGetValue(group, out var groupInfo) in MixKhronosData and read the surrounding code for more context)
  • Because this seems like an implementation detail / oversight to me, I want to make sure that this is intentional.
  • Decided to fix this since it affects the correctness of other transformations.

I also made it so that MixKhronosData does not skip over empty enum groups, which fixes the generation of[Flags] attributes and leads to a few more enums being generated.

Trimming

• ComponentSwizzle.ComponentSwizzleIdentity, etc is not trimmed properly. The enum name isn't getting trimmed here for some reason.
• ShaderStageFlags.ShaderStageVertexBit, etc is not trimmed properly
  • Guess: ShaderStageFlags is not a prefix of ShaderStageVertexBit Incorrect. This was the same issue as above.
• FixPipelineCompilerControlFlagsAMD.FlagBitsMaxEnumAMD, etc trimming
  • (Discuss) Didn't realize it when I first wrote this, but these are theMaxEnum members. We don't want these do we?
  • Note to self:Fix trimming first, then remove these members. TheMaxEnum members are the only ones that are named like this in the headers so we can just remove them. This isn't a trimming issue.
• Removing theMaxEnum members breaksIndirectStateFlagsNV.FlagFrontfaceBitNV due to no prefixes being shared by member names
  • Exhaustive list:IndirectStateFlagsNV,SemaphoreImportFlags,SemaphoreWaitFlags,SurfaceCounterFlagsEXT

Linux

• Remove Linux specific Clang workaround ineng/silktouch/vulkan/settings.rsp
  • I needed to add/usr/lib/clang/20/include as an include directory.20 is the Clang version.
• Discuss longterm solution for handling the Clang include directory. I know there isUnixStdIncludeResolver
  • I added support for finding the/usr/lib/clang/*/include folder to UnixStdIncludeResolver. It finds all matching folder patterns and takes the latest version.

Handling of Flags enums.

• (Fixed)DebugUtilsMessageSeverityFlagsEXT is not marked with the[Flags] attribute.
  • (Discuss) Looks like none of the Flags enums are marked with[Flags]. Does this functionality exist in Silk 3 yet?
    • Doesn't seem like it
  • Implemented by checkingKnownBitmask inMixKhronosData.Rewriter.
• (Discuss)DependencyFlags.None does not exist, but does in Silk 2. None does not exist in the Vulkan headers nor XML spec, so I'm assuming None was added by Silk itself.
  • AlsoShaderStageFlags.None
  • I attempted to fix this, but led to some unwanted outputs, such as names not being trimmed properly (does the trimmer check to see if all enum members share a prefix?). Also, knowing when to add in theNone = 0 member requires evaluating the value of the existing enum members. This is somewhat difficult because they look likeunchecked((ulong)0UL), which isn't trivially comparable to 0.
  • This might fit better in a TransformFlags mod so we can have this behavior in all Silk bindings.
  • It looks like we can useIFieldSymbol.ConstantValue for this
  • Implemented by usingsemanticModel.GetConstantValue in a newTransformEnums mod.

Incorrect typing for Flags/FlagBits enums

Original comment:These two issues are Flags/FlagBits specific issues. This disconnect causes ClangSharp to just output ulongs/uints. This is likely something we should fix on our side. We can fix this by looking at the NativeTypeName attribute.

Original comment:Some are trivial, but some NativeTypeNames look likeconst VkPipelineStageFlags *, such as in SubmitInfo.

• MemoryBarrier2.SrcStageMask does not use theAccessFlags2 enum and uses ulongs instead.
• DependencyInfo.DependencyFlags does not use theDependencyFlags enum and uses uint instead.
  • AlsoImageSubresourceRange.AspectMask
  • AlsoCommandPoolCreateInfo.Flags
  • AlsoFenceCreateInfo.Flags
  • AlsoClearAttachment.AspectMask
  • ...etc

This was fixed by parsing the type name from the NativeTypeName attributes and replacing the field/parameter type with the parsed type name.

Renaming of FlagBits to Flags.

Original comment:I recently found code that handles the FlagBits -> Flags mapping in MixKhronosData. I think the issue is that this code doesn't fully work yet so I'm looking into seeing how that code works and fixing that code.

• Remove code used to generate ClangSharp enum type remappings insources/SilkTouch/SilkTouch/Mods/MixKhronosData.cs.
• (Not implemented as originally planned) Automate the generation of ClangSharp enum type remappings
  • Actual implementation: Don't remap using ClangSharp. Use MixKhronosData.Rewriter to replaceFlagBits withFlags in identifier names globally.

Missing constants

• (Fixed) Not sure whereVK_LOD_CLAMP_NONE and other constants went.
  • Was due to the fake "API Constants" enum defined in the XML spec. Because of this, the constants were getting removed by MixKhronosData.

Generated function class should be namedVk

• Consider renaming the Vulkan class to Vk to match Silk 2
  • I decided to go ahead and rename it to Vk