On Wed Apr 12 21:47:16 2023 +0000, Francisco Casas wrote:
I think I did a poor job at explaining the problem, consider this example:
struct apple { float4 a[2] : REPEATED_OUTPUT; }; float4 main(out apple a[5], out float4 r : REPEATED_OUTPUT) : sv_target { // ... }In that case we will iterate 5 times through the apple struct, and try to add the REPEATED_OUTPUT0 semantic var 5 times, and also REPEATED_OUTPUT1 5 times. For each, the first time we create the semantic var, the **second time** we have to report the error, indicating that the first time the location was the same as now, and the following 3 iterations we need to ignore the error. But we also have to report the error for the `r` parameter. So the challenge here is knowing when we already have reported the specific error for a (semantic,index,location) trio. It took me some time but in v3 I came up with an strategy that achieves this by including additional flags in the hlsl_semantic struct, for whether it is in an hlsl_ir_var or in a hlsl_struct_field), that keep track of the errors already reported.
Honestly, I'm tempted to say that "you used an output semantic in an array variable; that can't work" is the kind of thing that deserves a slightly different error message than "you used an output semantic twice" anyway. Like, if I just saw "line 139: output semantic was already used, previous use at line 139", I feel like that takes a little more mental effort to figure out what I did wrong than "line 139: output semantic used inside of an array".
Along those lines, you'd want to just track whether there was an array (with size > 1) when iterating over semantics.
I'm open to disagreement on that point, though.