Call Vec::set_len() after checking for Vulkan errors

[MarijnS95]

The entire reason for calling unsafe set_len() after the Vulkan driver function call is to ensure the Vec never gives safe access to uninitialized values (as allocted via Vec::with_capacity()). This contract is broken within the implementation of these functions by temporarily setting a nonzero length when the Vulkan driver may not have initialized the underlying data at all, and communicated this by returning an error code.

Simply check the error code first, before jumping to a now-infallible codepath that calls .set_len() and always returns Ok().

TODO

We have to see what should happen in create_graphics_pipelines() and create_compute_pipelines() which always return the underlying Vec even on errors... 😰. Only do this if VK_PIPELINE_COMPILE_REQUIRED_EXT is returned (in addition to VK_SUCCESS), otherwise don't?

[Ralith]

We have to see what should happen in create_graphics_pipelines() and create_compute_pipelines() which always return the underlying Vec even on errors

This is intended. See Multiple Pipeline Creation:

When an application attempts to create many pipelines in a single command, it is possible that some subset may fail creation. In that case, the corresponding entries in the pPipelines output array will be filled with VK_NULL_HANDLE values.

[MarijnS95]

@Ralith thanks, so if I understand correctly these functions will always initialize every entry of the array, even if one or more failed to create; good to know!