Add missing handle comment for some VkObjectType values

[DadSchoorse]

For most VkObjectType values there's a comment with the matching handle name. Since they are the most elegant way to get the object type for a handle, I plan to use these comments to generate parts of Wine's vulkan code.

This PR adds comments to VkObjectType values that previously didn't have any.

[CLAassistant]

All committers have signed the CLA.

[TomOlson]

@DadSchoorse, this seems very fragile to us - naming a field "comment" implies that it is ignorable (not consumed by anything but human eyes) and optional (nothing breaks if you leave it out). If code is going to depend on it we will need to add CI to make sure we don't forget it when we add new types, et cetera, and we'd rather not.

The style guide specifies a fixed mapping between object type names and enum values, and we guarantee to enforce it in new types. Probably obvious by inspection, but the rule is "delete OBJECT_TYPE_ and camel-case what's left, except capitalize the extension suffix if there is one". We do that in at least one internal script. The only slightly crufty bit is recognizing extension suffixes, but vk.xml contains a complete list. We recommend getting the type names that way.

[oddhack]

As the XML maintainer / schema creator, agreed with @TomOlson. Comments can contain anything. While it has happened that we make an error in the naming scheme Tom describes, when we realize that we fix it by making the old, incorrect name an alias of the new, correct name.

[DadSchoorse]

The style guide specifies a fixed mapping between object type names and enum values, and we guarantee to enforce it in new types. Probably obvious by inspection, but the rule is "delete OBJECT_TYPE_ and camel-case what's left, except capitalize the extension suffix if there is one". We do that in at least one internal script. The only slightly crufty bit is recognizing extension suffixes, but vk.xml contains a complete list. We recommend getting the type names that way.

I considered this option, but it also seems fragile to me:
It needs the guarantee that no handle name contains any capitalized abbreviation.
Since struct names don't strictly follow this (e.g. VkGeometryAABBNV, VkPhysicalDeviceTextureCompressionASTCHDRFeaturesEXT) I concluded that future handle names might also contain completely capitalized parts.

[TomOlson]

@DadSchoorse that's a fair point - there are structure type names that violate the style guide, and we should by our rules create aliases for them. I'll raise an internal issue.

It's still the case that aside from 'comment="Optional"' in some of the query types, there are no other places in vk.xml where there is information in comment attribute values that looks like it is meant to have machine-readable semantics, and I expect the WG will want to keep it that way. For object types, string conversion does work today. I'll ping the WG and see what they want to do.

[expipiplus1]

There is a table generated in Vulkan-Docs/gen/refpage/VkObjectType.txt which contains this mapping, how is this generated (looks like it's written out by hand in chapters/debugging.txt and chapters/VK_EXT_debug_report.txt)?

(Note however that this table is incomplete, the missing rows are PrivateDataSlotEXT and DeferredOperationKHR).

[oddhack]

After some internal discussion we're intending to add an explicit new attribute on the handle <type> tags showing the corresponding OBJECT_TYPE token, and check the spelling consistency in CI. Also the table omission @expipiplus1 noted above will be fixed. Generating that table will be possible but we'll probably defer that part from the initial fixes. So this PR can probably be closed when we publish the XML updates in a couple of weeks.

[oddhack]

This should be fixed in the 1.2.163 spec update. There is a new 'objtypeenum' attribute on handle types specifying the corresponding OBJECT_TYPE enum.

[oddhack]

@DadSchoorse @SveSop @expipiplus1 please take a look at #1412. We don't want to just yank the comment= attributes out from under people's feet before they can switch over, but as there is a meaningful tagging scheme for this information now, we do want to remove them pretty soon - this is a chance for feedback.

[expipiplus1]

Thanks, @oddhack, that's very considerate. I'm not using these comments myself so of course this is OK with me :)

[DadSchoorse]

@oddhack I removed the code from Wine that uses the comments.