-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad handling of type tag with name attribute, rather than name tag #1462
Comments
FYI - we are in process of abandoning internal MR 5593 in preference to 5596, which introduces a new type for the PFN. So the fix in #1463, while still appropriate, isn't immediately required. Would appreciate feedback on internal MR 5596 however. |
That is, #1463 isn't needed at all? I'll close it then. It would just introduce unneeded complexity. |
It may be needed in the future, because this is part of the schema. In general we use <name> tags because the name has to be part of the tag content in any event, and having e.g. <type name="VkFoo">...typedef void VkFoo;</type> is redundant and error-prone - but there are occasional cases where a tag needs a name, so it can be used as a dependency, yet the name isn't needed in the tag content (usually something like external header dependencies which define types).
That is in fact what we did, but I don't think it's going to break anything given the very specialized use of this extension - the extension author signed off on it. |
I assume, you're referencing some vk.xml lines like For such a line, I would have expected a description like While the current line is kind of "annotated C code", the latter would be a bit more language independent. |
See internal MR 5593 for details but the gist is that we are trying to use an empty tag of form
to replace the explicit (re)definition introduced by the LUNARG extension in the latest spec update. Unfortunately, this causes the following error from the hpp-generate CI step:
Note that this has always been legal XML syntax, although accepting it may lead to another problem with Vulkan-Hpp, since there is then no explicit definition of the PFN type available - the PFN is just emitted along with the vkGetInstanceProcAddr prototype in the C headers. This is a new use case we haven't encountered before, all the other PFN types in the XML are explicit callbacks.
The text was updated successfully, but these errors were encountered: