My intention is to have this essentially as a debug and documentation tool. As the `assert()` implies, ideally in no case an IR error should ever be detected, because it is assumed that the frontend already generates correct code, or fails if some error in its own input is detected.
So we'd probably want to skip it when not developing/debugging then, right? That may also make it a bit more acceptable to do something drastic like calling abort() as the result of a validation failure, or doing potentially more expensive kinds of validation.
I think we already discussed this in the past, but I disagree: I find that using `assert()` is useful to document the assumptions of some piece of code. If those assumptions end up being violated, there are two sensible behaviors: 1) do nothing, hoping for the best; or 2) make the world explode, so that a developer is more likely to check why something that should have never happened really happened. You sound like you're from camp 1,
Not exactly, I'd like more options than those two. (In particular, I think "reject the specific input" is the right choice here. We can make it an ICE if you like.) Fundamentally though, my arguments are this:
- assert() is not a robust way to abort on unexpected input, even if we would like to abort the process instead of just aborting compilation of that specific shader. Calling abort() would already be better in that regard, although I think it's rarely appropriate for libraries to call abort() as well. - We're a library, we might get invalid or malicious input, and we can't possibly oversee all the consequences of aborting the calling process. (And I'll point out that that's just as true for d3d11 or d3dcompiler as it is for vkd3d-shader.)
And it shouldn't be terribly hard to think up scenario's where "abort the process on unexpected input" isn't the most appropriate course of action. E.g., imagine we're running some kind of shader translation web service. People submit their shaders to our web/application server, the server translates those shaders to the desired output format, and sends the results back. It might not be a terribly robust design to run shader translation in the context of the web/application server, but I don't think it's necessarily unreasonable, and who am I to judge. In this scenario, it would seem more appropriate to me to fail compilation when someone submits a shader that manages to trip our checks than to make the server explode.