SR error handling about rspirv

[kvark]

Does it make sense to try continuing parsing a module upon seeing the first recoverable error? We know for sure this module is no good, and we know for sure that changes are needed. We might as well just return with the first encountered error, in which case it's the same as unrecoverable.

[Skepfyr]

It depends on whether we expect anyone to be doing real-time correction of the errors. There are definitely benefits to just erroring out as soon as we see the first error, but it provides much less information to a user.

[kvark]

How do you see this real-time correction happening, and in what cases? Do you expect that the vector of correctable errors we return is complete, and by addressing each individual instruction the user will get a pass next time? If the user still have to iterate multiple times, then they might as well iterate on an error by error basis.

[Skepfyr]

Now I've explained it I think it's less likely to be useful, and really the chances that we get an incorrect SPIR-V module should be really small, as they will almost always be generated from GLSL/HLSL/etc. However, in the general case, providing as many errors as possible per pass is generally much more useful, consider programming rust, if it only gave you the first error you hit it would take absolutely forever to fix any problems.

[kvark]

I think we can look at WASM for inspiration here, not Rust.

Having an error in SPIR-V binary could mean that user's high-level code is wrong, but more likely this would happen if there is a bug in the high-level to SPIR-V translator. We shouldn't expect these bugs to be iteratively fixed in batches :)