Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
v4: tests: Get detailed information on failing tests.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
The only leftover field is SM1-specific, and I don't too much about how it's used, so I'm leaving it aside for now. It seems, however, that it could be moved directly to the parser (it seems to be only used for parsing and scanning).
--
v3: vkd3d-shader: Remove the bytecode fields from vkd3d_shader_desc.
vkd3d-shader/dxbc: Remove flag is_dxil.
vkd3d-shader: Move shader signatures to vsir_program.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/680
~~This applies on top of !656, the last three commits belong here.~~
--
v12: vkd3d-shader/ir: Sort each loop by block label.
vkd3d-shader/ir: Dump the loops in the control flow graph.
vkd3d-shader/ir: Keep track of loops by header block.
vkd3d-shader/ir: Keep a reference to the message context inside struct vsir_cfg.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/662
At some point I would like to have an assembler for TPF, so that it's easier to write and modify tests. This is a first step in that direction, fixing some kind of format for serializing signatures in the comment at the beginning of the assembler code. ~~I'm not decided yet on all details, so take this as an RFC for the moment.~~
--
v14: tests: Test emitting the signature.
vkd3d-compiler: Add an option to emit the signature when disassembling.
vkd3d-shader/d3d-asm: Support emitting the shader signature.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/553
> > I imagine this is to make vkd3d_shader_scan() more similar to vkd3d_shader_compile(), but I think vkd3d_unreachable() is worse than the existing code.
>
> Even if the source type is already validated by `vkd3d_shader_validate_compile_info()`? Which use do you see into validating the source type twice?
It's more about disliking vkd3d_unreachable()/abort(). That's a discussion we've had a few times before, of course; what's different this time is that we've seen a number of bugs come in through WineHQ Bugzilla with assertions failing inside vkd3d-shader since the last time we had that discussion.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/679#note_63881