Should we probably make `VKD3D_MAKE_TAG()` public too? And possibly `TAG_DXBC` too, after renaming?
An argument could probably be made for VKD3D_MAKE_TAG or something similar; I'm not as convinced about TAG_DXBC and all the others. Note that Windows already has MAKEFOURCC though. Personally I'd also happily defer this to a future release unless someone has strong feelings about it.
My understanding is that `free` usually means that the pointer itself is freed. Maybe this should be renamed to `destroy`?
Though I notice that this problem is also with `vkd3d_shader_free_shader_code()`, so maybe that's a ship that has already sailed.
It's a fair point, but we already have vkd3d_shader_free_messages(), vkd3d_shader_free_root_signature(), vkd3d_shader_free_scan_descriptor_info(), vkd3d_shader_free_shader_code(), and vkd3d_shader_free_shader_signature() with the same behaviour. I think that at this point doing something different for vkd3d_shader_free_dxbc() would just make things more confusing.
I don't like this too much. It behaves identically in what respect? Being NULL-terminated and UTF-8? Being regulated by `log_level`? I would just repeat the sentences that apply. It's a bit more verbose, but clearer, and you don't have to scroll to `vkd3d_shader_compile()` to understand the remark.
It's mostly just consistent with the existing documentation for functions taking a "messages" argument. Improvements welcome, of course, but this MR doesn't seem like the place for it.
I am tempted to say we might want to allow for specifying the tag and version here too. Or rather take a `struct vkd3d_shader_dxbc_desc` as input and ignore size and checksum (or even allow for flags to use them even if they're invalid).
Not that I have any real usage in mind, of course, so that should probably be ignored. I happen to like symmetry, and I don't see reason for having the parsing interface allowing for the hypothesis that a format change might in theory happen, and the serializing interface not doing the same.
I could be convinced, but I had this taking a vkd3d_shader_dxbc_desc structure originally, and it was mostly just an inconvenience when implementing D3DGetBlobPart() and D3DStripShader() on top of vkd3d_shader_serialize_dxbc(). It also implies adding validation for the tag and version. How about I change it if you can convince Zeb?
As a bottom line, I don't think a few tests would be harmful...
Fair enough. Between future vkd3d-utils and d3dcompiler usage and the existing usage of most of this code in vkd3d and vkd3d-shader I figured we had enough coverage, but I'll add some vkd3d_shader_api.c tests; either in a potential v3 or in a follow-up MR.