entry: Mark all extern "C" function-pointer calls unsafe

[MarijnS95]

We don't mark any of the extern calls to Vulkan function-pointers safe except for a few Entry functions. Their safety contract was easy to validate, but now that we exposed a constructor function to let the user provide function pointers in the form of Entry::from_parts_1_1() it is no longer safe to assume that we are calling the function that adheres to the contract specified in the Vulkan reference.

Because we don't rigorously do this validation and safe-marking anywhere else either, mark these function calls as unsafe.

Related discussion chain: #748 (comment)

[Ralith]

Did you want to also mark the individual methods as unsafe for consistency?

[MarijnS95]

Did you want to also mark the individual methods as unsafe for consistency?

We were not going to do that because the safety contract could be upheld on the Vulkan side, right? The only problem was that we can no longer validate this when the function pointer itself originates from an unknown source (e.g. not vkGetInstanceProcAddr).

Otherwise I would have gone for marking the functions as unsafe instead (to match all other Vulkan functions) and leave this function as safe (to match from_parts on Instance and Device) but we discussed the opposite in #748 (comment)?

[Ralith]

Both approaches are equally valid from a correctness standpoint. I understood from that conversation that you strongly favored the approach of marking the wrapper functions as unsafe for consistency?

[MarijnS95]

@Ralith yes they are, but since you put so much emphasis on (extern) C functions being not necessarily/inherently unsafe to call in #748 (comment), I figured the preference was to mark from_parts unsafe instead?

I haven't checked any of the safety contracts for these C functions, so we might as well mark them unsafe and keep the from_parts function safe (both matching how ash exposes the API everywhere else) then?

[Ralith]

you put so much emphasis on (extern) C functions being not necessarily/inherently unsafe to call

This was a point of fact, but is not necessarily the deciding factor. Apologies for the confusion!

I haven't checked any of the safety contracts for these C functions, so we might as well mark them unsafe and keep the from_parts function safe (both matching how ash exposes the API everywhere else) then?

I find this appealing from a consistency standpoint. Even though we can easily deem these safe, it might be confusing to do so when we in general don't.

[MarijnS95]

Ah, that makes sense then! Sure, I'll mark the C function wrappers unsafe instead.