Nikolay Sivov (@nsivov) commented about libs/vkd3d-shader/hlsl.h:
uint32_t is_separated_resource : 1;};
+struct hlsl_state_block_entry +{
- char *lhs_name;
- struct hlsl_block *rhs_instrs;
+};
Full syntax for an assignment is:
field_name = value; | field_name[index] = value;
Field name is indeed just a string, meaning we don't need to validate it when compiling for regular profiles, like ps/vs. It's validated only for fx profiles, so we get do it later at writing time. For error reporting it might be beneficial to add location for lhs name.
Index here is optional when parsing, some fields are not arrays. Index value is strictly a non-negative literal integer. Having 0 for a case when index syntax is not used is fine - zero is what's getting written, at least for fx_4+.
For a field value it's more complicated. It could take a few forms:
<var_name> - I think that's used for fx_2_0 only, and var_name is for example a texture object set for Texture field. expression that resolves to a literal numeric value - could be bool, int, or float value. It's later is coerced accordingly. var_name - sets value dynamically to a variable. var_name[literal_index] - sets value to a fixed element of a variable. var_name[var_index] - same, but index is a variable too. expression - expression here could be a lot of thing, including predefined function calls.
My point is, having hlsl_block here seems useful at first, but in practice it's only useful for expressions, and even then it's not compatible with them, because "instruction set" used for expressions is not the same as for the rest of hlsl.