No type information when using @typeInfo().optional.child

Help
,
1

I’m working on loading vulkan dynamically using reflection.
When including vulkan, if loading the function pointers dynamically you can
add a cDefine VK_NO_PROTOTYPES. This will exclude all
exported functions and only include the types for the function pointers. for example.

without VK_NO_PROTOTYPES

pub extern fn vkGetInstanceProcAddr(instance: VkInstance, pName: [*c]const u8) PFN_vkVoidFunction;
pub const PFN_vkGetInstanceProcAddr = ?*const fn (VkInstance, [*c]const u8) callconv(.c) PFN_vkVoidFunction;

with VK_NO_PROTOTYPES

pub const PFN_vkGetInstanceProcAddr = ?*const fn (VkInstance, [*c]const u8) callconv(.c) PFN_vkVoidFunction;

So the preferred way when loading the functions yourself would be to use the PFN_vkFnType types and thus add the @cDefine(VK_NO_PROTOTYPES, {}) to prevent accidental use of those functions.

So here is where I am running into issues. The following ways can be used to define a function pointer that we will assign to that is of type PFN_vkFnType

  1. Use the PFN_ type directly
const getInstanceProcAddr: PFN_vkGetInstanceProcAddr = undefined/null

This is not preferred as PFN_ types are nullable meaning with every call you would need to use

const addr = getInstanceProcAddr.?()
  1. Use reflection to get the underlying type
const getInstanceProcAddr: @typeInfo(PFN_vkGetInstanceProcAddr).optional.child = undefined;

This is preferred, because now it’s non nullanullble and I can call it directly without using .? syntax.
There is one issue with this. I lose all LSP information regarding this type, when hovering over it it will say @Type(unknown).

  1. Without using VK_NO_PROTOTYPES
const getInstanceProcAddr: *const @TypeOf(c.vkGetInstanceProcAddr) = undefined;

This works but in this case it means I cannot declare VK_NO_PROTOTYPES cleaning up the vk headers from functions I will never use.

I tried with both ZLS and zigscient-next lsp but got the same result.
For now I am going with option 3 because I do like having the type info available to me regarding the functions parameters and return type etc.

Is this an issue with ZLS? And if so are there any known work arrounds for these cases?

2

I think this is just a missing feature in ZLS. ZLS only supports a limited set of comptime operations, and I guess @typeInfo is not one of them.

But you can get the type without @typeInfo. The following gives me type information in ZLS:

@TypeOf(@as(PFN_vkGetInstanceProcAddr, undefined).?)
2 Likes
3

Nice solution! Many thanks!

edit:
At first glance it seemed to work, atleast for ZLS but this does not compile with zig 14.0

4

At first eye it seemed to work, ZLS provided indeed type info but unfortunately it does not compile :frowning:

    pub const getInstanceProcAddr: @TypeOf(@as(c.PFN_vkGetInstanceProcAddr, undefined).?) = undefined;

gives the compile error:

error: use of undefined value here causes undefined behavior
pub const getInstanceProcAddr: @TypeOf(@as(c.PFN_vkGetInstanceProcAddr, undefined).?) = undefined;

5

Instead of using undefined, using &0 seems to work. so it becomes:

pub const getInstanceProcAddr: @TypeOf(@as(c.PFN_vkGetInstanceProcAddr, @ptrCast(&0)).?) = undefined;
1 Like