Skip to content
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

Semantic tagging of pointer type for struct members #930

Open
zyrolasting opened this issue Feb 24, 2019 · 3 comments
Open

Semantic tagging of pointer type for struct members #930

zyrolasting opened this issue Feb 24, 2019 · 3 comments
Assignees
Labels

Comments

@zyrolasting
Copy link
Contributor

@zyrolasting zyrolasting commented Feb 24, 2019

Re: Additional Semantic Tagging

Someone cannot generate complete code for FFIs that explicitly distinguish C pointer types and non-pointer types with the current state of vk.xml. Take this selection of the specification, which shows a member with <type>void</type>* as opposed to something like <type variant="pointer">void</type>*.

<type category="struct" name="VkDescriptorSetLayoutCreateInfo">
    <member values="VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO"><type>VkStructureType</type> <name>sType</name></member>
    <member>const <type>void</type>*            <name>pNext</name></member>
    <member optional="true"><type>VkDescriptorSetLayoutCreateFlags</type>    <name>flags</name></member>
    <member optional="true"><type>uint32_t</type>               <name>bindingCount</name><comment>Number of bindings in the descriptor set layout</comment></member>
    <member len="bindingCount">const <type>VkDescriptorSetLayoutBinding</type>* <name>pBindings</name><comment>Array of descriptor set layout bindings</comment></member>
</type>

FFI generators for other languages would have to inspect CDATA immediately following <type> children of <member> elements or seek out a p-prefix to detect use of pointer types. This makes things harder, and I think an attribute should clarify how a member type is decorated such that an FFI binding stays in sync with generated C code

@krOoze

This comment has been minimized.

Copy link
Contributor

@krOoze krOoze commented Feb 24, 2019

Duplicate of #19.

@oddhack

This comment has been minimized.

Copy link
Contributor

@oddhack oddhack commented Feb 25, 2019

FWIW, the validity generator, which is a critical part of the spec, just keys off of the declaration text - see paramIsPointer in validitygenerator.py, and related functions nearby. https://github.com/KhronosGroup/Vulkan-Docs/blob/master/xml/validitygenerator.py#L156

@oddhack

This comment has been minimized.

Copy link
Contributor

@oddhack oddhack commented Mar 18, 2019

@zyrolasting I suggest this be combined with #931 and, if you propose some helper code in this regard, it could tag the AST or rewritten XML with additional information. But for our use, the simple-minded approach used by the validity generator has been reliable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.