Better errors for un-exposed APIs

[JAicewizard]

Hello, I am kind of a zig (and vulkan) noob, but i've been trying out these bindings to try some vulkan-compute benchmarks.

I have been following a "walkthrough" (https://www.youtube.com/watch?v=DPe4SxsUWyo) which has made my life very easy up to now.

However I just tried to enumerate devices and got into an issue because I had not yet enabled the API, which is entirely my fault.

This is completely my fault, but the error made it hard to track down:

.zig-cache/o/70260a5b43f66a7468cfd0c5a204f8b7/vk.zig:24052:41: error: no field or member function named 'vkEnumeratePhysicalDevices' in 'vk.InstanceWrapper(&.{ .{ ... } }[0..1]).Dispatch__struct_7612'
            const result = self.dispatch.vkEnumeratePhysicalDevices(
                           ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
.zig-cache/o/70260a5b43f66a7468cfd0c5a204f8b7/vk.zig:23999:24: note: struct declared here
            break :blk @Type(.{
                       ^~~~~

Would it be possible to instead, insert stubs that panic/return an error? (or ideally, throw a compile error when the unimplemented functions are used).

Other than that the bindings feel very nice to use up-to now :)

[Snektron]

Good idea, that shouldn't be complicated to add. Because they are fields and not types/constants, I don't think we can use @compileError or @hasDecl directly, but we should be able to replace the call by something like if (@hasField(Dispatch, "vkEnumeratePhysicalDevices")) ... else @compileError("an helpful message").

[InKryption]

Just a note to keep in mind when working on this: often a useful pattern for creating helpful error traces is to make return types be noreturn if the parameters or configuration would be erroneous in calling it, and then placing the compile error in the function - this is what I do in comath, such that erroneous use always points to the usage site, instead of some arbitrary decl in library/generated code.