ash-window: Make enumerate_required_extensions return &[*const c_char]

[swooster]

This PR makes enumerate_required_extensions return the same type that is expected by vk::InstanceCreateInfoBuilder::enabled_extension_names to slightly reduce the boilerplate needed to write small Vulkan apps.

[swooster]

Currently, the mismatch between what is returned by enumerate_required_extensions() and what is taken by vk::InstanceCreateInfoBuilder::enabled_extension_names() requires all Vulkan apps to write a bit of extra boilerplate to remap the list of extensions:

let extensions: Vec<_> = extensions
    .iter()
    .map(|ext| ext.as_ptr())
    .collect();

This PR will make that unnecessary.

[swooster]

Note: I don't think I've touched any of the areas with clippy warnings.

[swooster]

(rebased to incorporate #591 ... and fixed a relevant clippy warning now that the flood of others is gone)

[Ralith]

Thanks, I've been wanting this for ages!

[Ralith]

It should be noted that this will require ash-window's ash dependency to be collapsed down to the latest version once released.

[swooster]

(rebasing onto latest commit)

[Ralith]

Just holding off on merging until @MarijnS95 has a look since it's breaking.

[MarijnS95]

I've been hesitant to do this in the past because of not having lifetime annotations on *const c_char, but these are anyway all 'static and there's no owned Vec<> being returned anymore (separate, still valid change) which users could accidentally append their own pointers with different lifetime to (this is a problem I vaguely recall having in our own application surrounding extension names, but not sure how since these would have anyway been static string literals 🤔 ).

As such, this change seems totally fine and sensible to me.

Can we make fn const as a non-breaking patch release?

[swooster]

Can we make fn const as a non-breaking patch release?

This PR makes the names const in a separate commit from the breaking change specifically to allow that.

[MarijnS95]

@swooster We're still squash-merging here, so that'd have little effect unless the commit is transplanted to a separate PR (or #594 is reopened, retitled, and merged).

There are currently anyway very few changes (both on master and the open-PR-pipeline) that are non-breaking and would be interesting for a patch release. On the contrary, we have about 2-4 breaking changes queued up, so we might as well shoot for ash 0.37 breaking release straight away.

[MarijnS95]

Rebased to regenerate against 1.3.208 :)

[MarijnS95]

@swooster Are you aware that your email address used in the commits isn't associated with your GitHub account?

[swooster]

@swooster Are you aware that your email address used in the commits isn't associated with your GitHub account?

If the only difference between the two is that my github account is (my username)+github@gmail.com and my commit is (my username)@gmail.com then that's ok. If they're substantially different, then that'd be a bad sign.

I've gone ahead and added (my username)@gmail.com to my github account.

[MarijnS95]

@swooster it seems to be your initials + surname, separated with dots, at gmail dot com. See the Co-authored-by: field that GitHub generated for the merge commit 😉

EDIT: It looks like you added that address to your GH account as your name in those commits is now clickable and links back to your profile.