[cfe-commits] Removing redundant default cases

[Ted Kremenek]

On Sep 23, 2011, at 9:33 PM, David Blaikie wrote:

> Hi Ted,
> 
> I tried -Wunreachable-code earlier today (Chandler had suggested it as a way to find/remove the dead code after llvm_unreachables I'd migrated yesterday) & it produced some very... interesting output. It did find the dead code after llvm_unreachable but it also found some other very strange cases. I was wondering what was up with that. Good to know it's WIP - any tips on the state of that? anywhere I'd be able to lend a hand? 

Hi David,

The weirdest results I see from -Wunreachable-code tend to involve template code.  In templates, I've seen cases where a branch condition depends on a template parameter, and at template instantiation the branch condition may become a constant.  This can cause some code to (correctly) be flagged as unreachable for that particular instantiation of a template.  This of course is not an invariant for that template for *all* instantiations, so it's not a real issue.

The solution I had in mind to fix this problem is to enhance the CFG.  Instead of just pruning CFG edges, for templates we could record when an edge was pruned AND whether or not it was dependent on a template parameter.  Most analyses would  continue to see the CFG as they do now, but specific analyses (such as -Wunreachable-code) could do something a bit more clever and not treat such code as unreachable.

> 
> It wouldn't catch all the same cases ("case N: default: stuff" for example) but this solution isn't great either, it'll catch a variety of arcane cases that won't have trivial fixes.

Ah, interesting.  -Wunreachable-code looks for finding unreachable basic blocks, not looking at whether or not a label could never be used.  Those are different concepts.

> Chandler had mentioned the idea of this warning (well, something like it) yesterday but after I threw this together we were talking about it more & realized it'd be pretty tricky to get right with a nice multiline fixit that is very reliable (I get the impression that's what he's really interested in - really low (0?) false positive rate & accurate fixits - which would be awesome, but require a rather different fix)

I agree.  A warning like this in the compiler needs close to a zero false positive rate.


Cheers,
Ted