[cfe-commits] r62245 - in /cfe/trunk: lib/Sema/CMakeLists.txt lib/Sema/IdentifierResolver.h lib/Sema/Sema.h lib/Sema/SemaCXXScopeSpec.cpp lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExpr.cpp lib/Sema/SemaExprCXX.cpp lib/Sema/SemaL

Douglas Gregor dgregor at apple.com
Fri Jan 16 15:00:13 PST 2009


On Jan 16, 2009, at 2:47 PM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>> Can anyone point out a flaw in the code under discussion? It will
>> produce the appropriate warnings if we miss an enumerator, and it
>> doesn't seem to trigger any additional warnings under any particular
>> compiler or compilation flags. It's not broken, so why are we trying
>> to fix it?
>>
>
> The real question is, should we change other places to do it the same
> way? Should we adopt it as our new policy?
>
> Or does the existing policy mean that your code should change for the
> sake of uniformity?

I'm not convinced that we ever had a policy. At least, it's not in the  
LLVM coding standards, and IIRC it hasn't come up before.

It makes sense to

	default: assert(false && "Something");

when we don't expect that our switch statement will handle every case;  
this is most of what we see in Clang, because we're switching on the  
kind of a statement or declaration and we won't be handling everything.

In the code we're discussing, it does not make sense to add such a  
default case, because doing so suppresses a useful warning, while the  
code that's currently in Subversion does not appear to have any  
negative side effects.

If there is a policy on this, then either I'm missing something (some  
other compiler complains, perhaps) or the policy is wrong. At this  
point, I'm disinclined to make any change here unless someone could  
point me at either a written policy or show that the code we have  
causes some kind of problem on some compiler.

	- Doug



More information about the cfe-commits mailing list