[3.0] Improve handling of Khronos enum native names

[Exanite]

Summary of the PR

This changes the native name for namespaced enums like GLEnum to be GLenum.
In the process, I also found a bug where Vulkan enums had inconsistent native names.

Related issues, Discord discussions, or proposals

Discord conversation: https://discord.com/channels/521092042781229087/587346162802229298/1460042806952198310
PR where this issue was first discovered: #2503

This PR contains the following sub-PR:

• [3.0] Fix missings [Flags] attribute on certain OpenGL enums; Require explicit typemap for enum base types Exanite/Silk.NET#30

Further Comments

N/A

[Exanite]

Self review complete. Marking as ready for review and subsequent merge.

[Perksey]

Are we sure that hardcoding GLenum is correct here?

[Exanite]

This parameter specifies the base type of the enum and matches the code in the "Parse enum members" for loop below.

MixKhronosData has a type map during InitializeAsync that is hardcoded to add GLenum as an entry:

job.TypeMap.TryAdd("GLenum", "uint");

Not specifying the type in the new EnumGroup code means that the enum group is skipped when MixKhronosData goes to generate the enum later:

Enum "ALEnum" has no base type. Please add TypeMap entry to the configuration. This enum group will be skipped.

Compared to before, this is now needed because this line of code takes precedence over the new EnumGroup code in the "Parse enum members" for loop, meaning that it needs to take responsibility for initializing the base type in certain cases.

[Perksey]

I think this is fine. We can remove the hardcoded GLenum in the TypeMap for consistency if desired, the intention behind this was to have a "sensible default" for the configuration.

I don't want the mod to be hardcoded to OpenGL specifically, as OpenAL is one example of a GL-style binding. GLenum is not an OpenAL type and our code doesn't have any business assuming that ALEnum is the same as GLenum and therefore uint, considering the rest of the code is agnostic to this.

[Exanite]

That makes sense. I assumed the intention behind using GLenum specifically was to indicate that the enum is a GL-style enum, not specifically that it was a GLenum.

GLbitfield is also declared in the type map, but it is not used anywhere.

It looks like the code that handles OpenCL later just hardcodes the base type, so this change would be consistent with that approach:

Proposed change:

Also debating if I want to pull the result of the condition into a variable so we don't have issues when we modify one, but not the other in the future. However, I don't want to wrongly imply that the resulting type needs to be used as a default (there are four places where we use new EnumGroup).

[Perksey]

I believe both of these cases should not hardcode a specific integer type. The OpenCL one is likely a leftover from the admittedly quite complex OpenCL-specific logic ported from BuildTools, I agree this new change is consistent but hardcoded logic for determining what the enum base type should be should be avoided, as this changes depending on what we're binding to and therefore should be specific in the configuration, optionally with "sensible defaults" in MixKhronosData that the configuration overrides.

[Exanite]

Do you have a specific change in mind?

One approach for OpenGL/AL is to have the type be based on the namespace (eg: GLenum, ALenum, etc).
I'm unfamiliar with OpenCL so I'm not sure if the same approach will work there.

That being said, it should be "safe" to leave the type map unspecified (as in, not provide defaults for the config to override) since the generator will log errors and skip over enums that don't have base types. Anyone working on the bindings should be able to quickly see that and fix it by updating the configuration.

[Perksey]

Leaving it unspecified and updating the configuration is what I had in mind.

That being said, ideally we don't want every single enum to be specified in the config, so we do really only want it to be the base types. For the OpenGL code, this should be an easy case of using $"{namespace}enum".

For the OpenCL code, I'm not quite sure how to make this more generic primarily because that logic is so esoteric and there's a lot hardcoded already, I would just suggest hardcoding this to cl_bitfield and we'll have to look at it in depth another time unless you can see something obvious that follows the same spirit as the OpenGL change.

[Perksey]

Wrt OpenCL, I think removing all the hardcoded stuff is likely a larger work item, so the best we can do is not make this problem worse and tackle it another time.

The changes likely aren't that complicated:

• This loop removes knowledge of cl_properties/cl_bitfield, and instead of checking for those specific types should check whether the inner type element has a name in TypeMap.
• Configuration should contain a bitmask types array, that if not provided has sensible defaults (i.e. cl_bitfield)
• Additional work to either use other data within the registry in place of hardcoded cl/CL in strings, or to derive this from configuration.

But your call on how much to do for this PR, it does feel out-of-scope.

[Exanite]

I haven't looked into OpenCL yet, but I agree, I'd much rather do this once we start working on the OpenCL bindings so we can review the output and work with actual data. Trying to rework the OpenCL code without looking at the output seems like a recipe for disaster.

[Exanite]

This PR will be ready for review/merge once Exanite#30 is merged into this PR.