================
@@ -102,6 +102,7 @@ static ResourceClass getResourceClass(RegisterType RT) {
return ResourceClass::Sampler;
case RegisterType::C:
case RegisterType::I:
+ default:
llvm_unreachable("unexpected RegisterType value");
}
----------------
farzonl wrote:
I don't agree with the suggested change of not using default.
@hekota says:
> the switch covers all enum values.
It sounds like line 107 will be impossible to hit.
So then whats the difference between an unexpected and an unhandled register
type? Why couldn't we have just done a default case? Why can't MSVC2022
determine that all cases are covered? Are we really making a change to appease
a false positive from a compiler warning?
If a new Register Type were added it would hit a llvm_unreachable on the
default case and an implementer would quickly know to implement it from the
call stack. I don't like the idea of changes to make a warning happy when that
code change adds undistinguishable terminology between unexpected and
unhandled. I would prefer not adding new terminology that would be confusing
and instead add a default.
https://github.com/llvm/llvm-project/pull/112767
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
