<br><br><div class="gmail_quote">On Thu, Oct 6, 2011 at 8:47 PM, Matt Beaumont-Gay <span dir="ltr"><<a href="mailto:matthewbg@google.com">matthewbg@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Thu, Oct 6, 2011 at 20:25, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> @@ -666,6 +666,7 @@<br>
>>        default:<br>
>>            assert(false && "Unhandled Opcode.");<br>
>>     }<br>
>> +    return static_cast<LLVMOpcode>(0);<br>
><br>
> If you used llvm_unreachable instead of assert(false) in that default case,<br>
> then you should be able to go without the (effectively unreachable) return<br>
> here.<br>
><br>
> And/or you could skip the default entirely if your switch covers all the<br>
> values of the enum - I sent out a CR to remove all these unnecessary default<br>
> cases (in both clang & llvm) a while back but I'm not sure anyone said 'yae'<br>
> or 'nae' to it.<br>
<br>
</div></div>I have no strong feelings on this matter. If there is a preferred<br>
style, it should be documented on the Coding Standards page.</blockquote><div><br></div><div>Indeed - it (requesting people remove default cases on switches that cover all enumeration values) seems to come up as fairly common CR feedback, at least on cfe-commits but I haven't seen a clear statement in the coding standards. <br>
<br>I'll see about getting some discussion towards formalizing the approach on llvm-dev or the like.</div><div><br></div><div>- David</div></div>