document calling convention to load() better, PfnGetInstanceProcAddr may not be the right calling convention for most

[slimsag]

vulkan-zig currently declares vk.PfnGetInstanceProcAddr as using the vulkan calling convention:

pub const PfnGetInstanceProcAddr = fn (
    instance: Instance,
    p_name: [*:0]const u8,
) callconv(vulkan_call_conv) PfnVoidFunction;

But this is not a Vulkan proc, it's a C proc which returns Vulkan procs and should use callconv(.C). For example, GLFW's C API does not define glfwGetInstanceProcAddress as using the Vulkan calling convention, but rather the standard C calling convention

For now, this just happens to work because vulkan_call_conv is the same as callconv(.C) on all platforms except windows-i386 (.Stdcall) and android-arm (.AAPCSVFP) which have presumably not been tested with zig-vulkan.

[Snektron]

It's valid for vkGetInstanceProcAddr to resolve itself, in which case i would think that the return value is a PfnGetInstanceProcAddr with the vulkan calling convention. In this sense, PfnGetInstanceProcAddr is a pointer to vkGetInstanceProcAddr as provided by Vulkan itself, and not one as provided by the loader platform. Note that this is also the reason why load on Wrappers accept anytype for the loader function, instead of a PfnGetInstanceProcAddr.

[slimsag]

Ahhh, I see, that's very interesting. I didn't realize vkGetInstanceProcAddr could resolve itself, that makes sense.

Given that, I would suggest maybe some documentation around this as it seems highly likely others will fall into the same trap of casting to PfnGetInstanceProcAddr and thinking it's the right calling convention. I was suspicious enough to find the load code was compatible with any calling convention, as you already mentioned, but I'm not sure others will pay such careful attention.

[Snektron]

Implemented in c169871