You can't use names from 3.12 Image Channel Order and
3.13 Image Channel Data Type since in the intstruction grammar,
they are only used as return values, but never named arguments
to instructions.
This is in preparation for coming tests that will also
use the templated EnumCase instead of making their
own structs.
Also reformat AccessQualifier test.
Add a new operand type SPV_OPERAND_TYPE_MULTIWORD_LITERAL_NUMBER
to represent those operands that can expand into multiple words.
Now only OpConstant and OpSpecConstant have such kind of operand.
You can't use a named enumerant if it's only meaningful
in an operand supplied as an ID to a target instruction.
The place where you'd use the name is something like an
OpConstant, but there's not enough context to bring those
names into scope, unless you're willing to tolerate
potential collisions.
Occurs for the names in:
- 3.25 Memory Semantics
- 3.27 Scope ID
- 3.29 Kernel Enqueue Flags
- 3.30 Kernel Profiling Info
Added a new enum for supported assembly syntax formats:
Canonical Assembly Format (CAF) and Assignment Assembly Format (AAF).
Updated assembler interface functions to support choice of assembly
syntax format.
Added diagnostic messages for what should be an internal failure
that never happens. I figure if we return "failed" for something the
user cannot control we should print a message for it.
The undefined pointer might get through to the call
to spvTextDestroy if the test fails on an earlier step.
In that case I just want to see the test failure, and
not a test failure followed by undefined behaviour.
Add text_fixture::TextToBinaryTestBase::CompiledInstructions,
to more easily just examine the generated instructions by skipping
over the header.
Add spvtest::MakeInstruction utility function to easily generate
a vector containing an opcode and its operands.
Previous the api used spv_text_t and spv_binary_t for both input
and output, but depending on the usage, you either MUST
call spvBinaryDestroy or you MUST NOT call spvBinaryDestroy on the
pointer.
Always try to destroy the binary during common methods
of test fixtures. This is safe if no other code in the test
attempted to destroy the binary.
Take advantage of the fact spvBinaryDestroy is a no-op on a nullptr,
by eliminating the null pointer check in the caller.