`sm4_sort_externs()` only cares about sorting resources relative to other resoures; for writing the RDEF section.
Structs themselves don't appear in the RDEF section so any comparison function is okay for them as long as it is consistent.
Ahh, right. To be clear, structs *do* appear in the RDEF, but not in the bound resources list, and sm4_sort_externs() only affects the order of bound resources.
Actually, I didn't remember or notice, but sm4_sort_externs() only sorts variables with a data type of HLSL_CLASS_OBJECT. We should probably just change that to hlsl_type_is_resource() and then we don't need this check.
Uniform structs containing objects are only allowed in profiles >= 5, and in those profiles these components have to be promoted to individual variables, so they are not to be shown either.
I know that they show up as separate variables in the RDEF section, but I... don't think we actually need to make them separate hlsl_ir_vars, do we? I don't hate the idea, but let me pitch an alternative to see if it's more appealing:
Thinking out loud here, but what if we did multiple passes over the extern vars list—sampler, then texture, then UAV or whatever the order is—and instead of the aforementioned "hlsl_type_is_resource()" check for sorting it'd become "var->regs[regset].allocated"?
We already do 3 "passes" over ctx->extern_vars (one for the count, one to write most of the data, one to write the strings) and this would make that uglier, but we could, say, build some sort of temporary array first instead, and that might help a bit. (And that would also sort of collapse the cbuffer/resource difference a bit.)