-Wunreachable-code vs -Wcovered-switch-default

Hi all,

consider the following example code:

#include <stdlib.h>

enum e {E1, E2};

int main(int argc, char* argv)
{
        enum e e = atoi(argv[argc-1]);
        switch(e)
        {
                case E1: return 1;
                case E2: return 2;
                default: return 3;
        }
}

If compiled with Clang with -Wcovered-switch-default, it rightly warns
about the default case. This can be suppressed when intentional by
using -Wno-covered-switch-default. If compiled with
-Wunreachable-code, it will also warn on that line, but it seems that
that warning cannot be silenced when intentional without also
silencing all other occurrences of unreachable code in the file
("-Wunreachable-code -Wno-covered-switch-default" still warns).

I'd like to get warnings if there is unreachable code in the general
case, but not have it warn on covered switch defaults. Is there a way
of accomplishing that?

Best Regards
Magnus Reftel

Hi all,

consider the following example code:

#include <stdlib.h>

enum e {E1, E2};

int main(int argc, char* argv)
{
        enum e e = atoi(argv[argc-1]);
        switch(e)
        {
                case E1: return 1;
                case E2: return 2;
                default: return 3;
        }
}

If compiled with Clang with -Wcovered-switch-default, it rightly warns
about the default case. This can be suppressed when intentional by
using -Wno-covered-switch-default. If compiled with
-Wunreachable-code, it will also warn on that line, but it seems that
that warning cannot be silenced when intentional without also
silencing all other occurrences of unreachable code in the file
("-Wunreachable-code -Wno-covered-switch-default" still warns).

I'd like to get warnings if there is unreachable code in the general
case, but not have it warn on covered switch defaults. Is there a way
of accomplishing that?

Not just yet, but there probably should be.

I've been working on & off (more off) on improving the underlying
infrastructure for this warning to allow more precision that would
also be a necessary prerequisite to the improvement you've described.
So it's a bit of a ways off yet, but we shouldn't lose track of it.

If you'd like to file a bug (llvm.org/bugs) and assign it to me,
that'd be great.

- David