Fix struct generation with constant size arrays

[aloucks]

PR #191 introduced a bug into the generator where constant sized array struct fields were generated as slices. This PR adds a flag to type_tokens that will revert that behavior while still generating FFI function signatures with pointers instead of fixed sized arrays (e.g. for set_blend_constants).

In addition, all instances of HashMap and HashSet have been replaced with BTreeMap and BTreeSet, which makes the generation of vk.rs idempotent for the same vk.xml input. This should obviate the need for #130 and make it much easier to see how changes to the generator or vk.xml affect the generated output.

[Ralith]

all instances of HashMap and HashSet have been replaced with BTreeMap and BTreeSet, which makes the generation of vk.rs idempotent for the same vk.xml input.

This is a great thought, but I think it's dramatic overkill; most HashSets and HashMaps are used for random access, not walked sequentially. In fact, skimming around the code I'm not finding a single case where we're iterating through either.

[Ralith]

Also, do the last two commits need to be separate?

[aloucks]

all instances of HashMap and HashSet have been replaced with BTreeMap and BTreeSet, which makes the generation of vk.rs idempotent for the same vk.xml input.

This is a great thought, but I think it's dramatic overkill; most HashSets and HashMaps are used for random access, not walked sequentially. In fact, skimming around the code I'm not finding a single case where we're iterating through either.

Here's one:

https://github.com/MaikKlein/ash/pull/193/files#diff-02cf551bd84acec65d3adf3311783cdfR2148

https://github.com/MaikKlein/ash/pull/193/files#diff-02cf551bd84acec65d3adf3311783cdfR2246

I don't really see the BTree variants posing any issue given that the generator isn't performance critical code. If it were, I'd probably opt for FxHashMap over the one from std. The benefit is that we can rest assured that vk.rs will be generated exactly the same every time.

For what it's worth, I didn't notice any particular performance difference after the change, but I wasn't timing it either.

[aloucks]

Also, do the last two commits need to be separate?

They're now squashed.

[Ralith]

You're right that it's not performance-relevant; I'm just not a huge fan of using a less-conventional tool where a conventional one will do fine, as it misleadingly invites the reader to wonder what the unusual requirement is for cases where there is none.

[MaikKlein]

I am super confused how this is even correct in 0.28. I think #191 didn't actually run the generator and then I just rebased in the changes. I'll give you a proper review during the day.

[aloucks]

@MaikKlein Yeah, that was the conclusion I came to as well. Running the generator is a little scary when you see all of vk.rs change. Prior to these changes, it was very difficult to see how changes to the generator affect vk.rs.

This PR is actually a pre-cursor to the changes that I wanted to add. I ran into issues with being unable to build after re-generating, thus this PR was born to correct that first.

Once this is (hopefully) merged, I'll put in a PR for adding doc links to the Khronos man pages for every struct and function. This makes both rustdocs and IDE auto-completion much nicer (IMO).

Preview:
aloucks/ash@constant_size_array_generation...aloucks:khronos_doc_links

[MaikKlein]

Using BTreeXXX for ordering is fine I think. Using a bool to differentiate between ffi and fields is also okay.

[Ralith]

Using BTreeXXX for ordering is fine I think

My (weak) objection was against using it for cases where ordering is not observed. In the cases where ordering is observed, it is a great solution.

[MaikKlein]

My (weak) objection was against using it for cases where ordering is not observed. In the cases where ordering is observed, it is a great solution.

A valid argument. Kind of hard to see where a BTreeMap is required purely by the diff. I'll have a closer look at it tomorrow to see where it is really needed.

[aloucks]

@Ralith @MaikKlein Updated the generator to use BTreeMap only where ordering is observed.

[MaikKlein]

bors r+

[bors]

Build succeeded

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push

[MaikKlein]

@aloucks Thanks for the PR, contributions are always appreciated :).