GitLab

All bitmasks can have an empty 'zero' value, and all enums start with at
least a single named zero-value, so there is no need to have separate
logic for 'allowing empty'.

There is no point in parsing and dealing with the VkStructureType in the
context of these libraries.

When the files are compiled with Vulkan header versions outside of the
compiled range, the compiler message will now state the min/max version
that is supported, instead of a fully generic message.

Added explicit use of the docker.io domain.

The temporary internal string could be leaked if the return was called
before the free, or if at the end the serializedLength was 0.

The sanitizers help to find issues dealing with memory, undefined
behaviour and other hard-to-find types.

More options, results from both coverage tests can nw be merged into one
report.

better usage instructions for value serialization, and now reflects the
C/C++ split.

Add test cases that cover NULL or zero-sized types, testing parsing of
64-bit templated types, and the behaviour of 'incomplete' serialization.

Some newer types, such as VkPipelineStageFlags2 has numeric values at
the end, leading to issues where the assumption of 'Flags' or 'FlagBits'
always being at the end no longer held true. This would lead to where
generated prefixes were incorrect, where the flags/bits were being added
to the prefix, and where the number values were being improperly added.

Instead of the desired prefix of:
VK_PIPELINE_STAGE_2_
it would generate this:
VK_PIPELINE_STAGE_FLAG_BITS2_

Thus, a new method of detecting the Flag/Bits using strstr, and instead
of manipulating the length of the string, it would advance the character
pointer when it reaches it.

As well, adding the case of inserting an underscore when a numeric value
is detected.

Converted the majority of the functionality of the Vulkan value
serialization library to compile in C. All that is left on the C++ side
is the macro and templated functions that abstract away very surface-
level complexity.

Checks that the headers can be compiled under their respective supported
languages.

The result to string header is supposed to be fully C-compatible, but
was using the C++ static asserts instead.

Slightly better readability, avoiding the auto-formatting mangling that
occurred with the previous section.

Rather than using the writelines function with split strings, changed to
have a single formatted string which is then output.

When it comes to generating the serialization header, not having
duplicate sets is a boon.

Rather than the values being directly under the type node, it is now
buried one layer deeper under 'values'. This will allow for adding a
'platforms' set under the enum node.

When serializing, the order that values were parsed could have an affect
on what is output as part of serializing values. The last value that
matched the value would always be used, even if that value was an
aliased value to a possibly promoted newer value.

To deal with this, the sets of enum values now have a new 'alias'
boolean which describes whether the value is aliased, and if so, will be
skipped for serialization. Per value, there is only ever one non-aliased
value, from which all the 'aliased' versions copy that value.

The reason these aliased values still exist in the sets is still for
parsing from data and programs using older versions of the Vulkan
standard.

Can greatly speed up development by not having to re-generate the cache.

Rather than using the 'writelines' function which passes an array of
strings, uses strings formatted through native strings functionality for
more readable code.

For the most part the EnumValueSets have been re-ordered since how enums
are parsed from the Vulkan XML have modified how they are output.

For actual changes however, many enum types that do not have any values
now have entries in the enumTypes array, with no array but placed there
so zero-values can be parsed and serielized. As well, duplicate sets of
enums that have been promoted between vendors have been merged into the
latest set (ie 'aliased' sets now point at newest variant of the enum).

Rather than adding enum and bitmasks as they have values appear in the
Vulkan XML, they are all collected from the initial types/type section.

This does allow for adding some more pertinent information, such as
alias information that can be used to better build relationships in the
end.

When a compare function was called from another as part of the initial
trivial check set, the inverse of what was desired was sent back. So
while the sub-type was equal, the calling type would think it wasn;t.

Inverting the call point resolves this.

The headers need a few passes for some reason to format properly.

MSVC has a nested block limit of 128, and if/else chain counts as that.
Thus MSVC would hit this limit when compiling the cleanup header.

A fair number of extension struct types have been promoted and as such,
renamed to lose vendor suffixes.

However, these aliases were not tracked nor accounted for, so structs
that would have required work for cleanup or comparison were treated as
if they had no members at all.

The parsing script has been updated to pass alias information along, and
the cleanup/compare generation scripts updated to follow any alias and
use those member instead.

As well, because some structs have had members added or removed through
specification revisions, members also get first/last information to help
properly guard them.

Because of aliases however, using the switch case no longer works as
there are multiple enums for the same value, so changing to a big
if/else chain had to happen.

Doing simple comparisons of struct-local data only.

As the Vulkan spec has progressed, some associations between functions
and definitions have changed, when items have been promoted or certain
extension/platform names have been removed.

Rather than requiring all platforms to be defined, structures may exist
if at least one of the platforms are defined. As such, they should be
what is checked for instead using OR.

Also added the ability to manually exclude certain structs for whatever
reason. Currently because I don't know how to implement some bits and
have no need to yet.