Francisco Casas (@fcasas) commented about libs/vkd3d-shader/hlsl.y:
YYABORT;}if (hlsl_types_are_equal($3, ctx->builtin_types.Void) && $8.semantic.name){hlsl_error(ctx, &@8, VKD3D_SHADER_ERROR_HLSL_INVALID_SEMANTIC,"Semantics are not allowed on void functions.");}if ($8.reg_reservation.type)FIXME("Unexpected register reservation for a function.\n");if (!($$.decl = hlsl_new_func_decl(ctx, $3, $6, &$8.semantic, $1.count, $1.attrs, &@4)))YYABORT;$$.name = $4;ctx->cur_function = $$.decl;}
My understanding is that the first part of this block of code for the case ``` var_modifiers type var_identifier '(' parameters ')' colon_attribute ``` should be the same as the previous case: ``` | attribute_list var_modifiers type var_identifier '(' parameters ')' colon_attribute ``` but with the arguments shifted.
In that case, I see a discrepancy in how modifiers are handled, since matrix majority modifiers are allowed.
Also, to avoid redundancy, it is possible to put the former case on an intermediate rule for the parser?
For instance, if we call this rule `func_prototype_without_attrs`: ```c func_prototype: func_prototype_without_attrs { return $1 } | attribute_list func_prototype_without_attrs { $2->attr_count = $1.count; $2->attrs = $1.attrs; return $2; } ```
Of course that would mean that it wouldn't make sense to add the `attr_count` and `attrs` parameters to `hlsl_new_func_decl()`.