Fundamentally, I think vkd3d-shader compiler output should go through vkd3d_shader_message_context instead of TRACE/WARN/FIXME/ERR.
Yes, although I think there's also clearly some things that belong in the debug channels. We still have a few FIXME that should be hlsl_fixme(), but...
Sure; and I think hlsl is pretty decent at this these days. That's not necessarily the case for some of the other code, like dxbc-tpf or spir-v.
The question would then be whether the existing API is sufficient for d3dcompiler, vkd3d, and wined3d. If it's not, we could certainly introduce additional API to fix that. For example, we could introduce callbacks that receive compiler output with the location, log level, error code, and message already separated out. It's not necessarily clear to me that some variant of what wined3d does in shader_spirv_compile_shader() wouldn't be sufficient for d3dcompiler/vkd3d though.
Broadly, except that currently the program might suppress the log level, and we probably don't want to print warnings by default.
If we're talking about D3DCompile2(), I don't think that does log levels? We always pass VKD3D_SHADER_LOG_INFO, at least. The application may decide to pass NULL for "messages_blob", of course, but we still retrieve the messages from vkd3d_shader_compile() in that case; we'd just have to output them.
I'm personally not too worried about outputting warnings by default from D3DCompile2(), but at least in the cases where applications pass NULL for "messages_blob" we could also adjust the log level based on the enabled Wine debug channel. If we're particularly worried about this we could try to filter the messages or recompile with a different log level. I'm not necessarily convinced that's worth it, but the option does exist.
If we do end up introducing API for this, I'd want to be fairly careful about it; ideally we wouldn't need to introduce a v2 and v3 of that API within a couple of releases.
Actually, I guess now is a good time to bring up a related discussion—the error code schema doesn't make much sense to me currently. I can see the point of applying codes to warnings, so that they can be selectively disabled. I'm not sure it's the best way to handle it in general, though. I think the gcc approach is more expressive and allows reclassifying some warnings, e.g. you can divide up what was previously one warning into multiple by applying an extra argument (consider -Wshift-overflow). I suppose we could claim no API stability around warnings, though; it's not like gcc guarantees that either...
I don't see the point of applying codes to errors, though. Disabling or even reporting them selectively doesn't make sense.
The other main RFC related to warnings is: currently we have not been matching the native HLSL compiler at all with respect to warnings. Should that change? One good reason it potentially should is to allow "#pragma warning" to work as intended.
A few considerations went into this:
- If I were to get e.g. an "E5003: Argument to preincrement operator is const." error from vkd3d-compiler, it would be relatively straightforward to map E5003 back to VKD3D_SHADER_ERROR_HLSL_MODIFIES_CONST, and find all the places in vkd3d-shader that could possibly generate that error. It would be slightly harder to get there from just the message. Similarly, it would be relatively straightforward to search for error codes in e.g. Bugzilla.
- I don't know whether we'll ever get translations for vkd3d-shader output, but it's certainly a possibility. This would only amplify the previous point.
- I'm not aware of any applications that depend on receiving specific error codes from the HLSL compiler, and I certainly hope they don't exist, but stranger things have happened. If we do ever run into one of those, we'd have the ability to remap error codes in d3dcompiler.