[PING][BUG] -Wunreachable-code not working

Clang Frontend
1

HI all,

I'm reporting this bug here since the LLVM Bugzilla requires
registering an account (which can't be done by myself manually).

Basically, this code triggers the warning:

int main()
{
    return 0;

    int a = 42;
}

while this doesn't:

#define A 42

int main()
{
    return 0;

    int a = A;
}

This happens on clang++-6.0. I'm not using any options other than
-Wunreachable-code.

2

I didn't look at these clang warnings specifically, so i might be completely wrong, but i suspect that a lot of warnings are suppressed in mere presence of macros. It is just too easy to produce weird code by combining completely valid macros. Probably not the best example but gives a rough idea:

#ifdef WINDOWS
#define SHOULD_USE_X 0
#else
#define SHOULD_USE_X shouldUseX();
#endif

if (SHOULD_USE_X) {
// Should we emit a deadcode warning here under Windows?
}

Such suppression might probably be made less brutal, but i'll be surprised if it were possible to get away with not having it at all. And it's pretty tricky to find deadcode before the preprocessor runs, when you're still capable of accidentally concatenating 'ret' and 'urn' into 'return'. So it's not the most pleasant problem to solve, and it's usually not that terrible when we don't give a warning (it's much less terrible than emitting a warning that's not actionable), so people usually make various suppressions for this sort of stuff.

3

Agreed, but wouldn't it make more sense that the dead code
identification happened after the preprocessor is done? I know nothing
of clang internals, that's just what makes sense to me.

4

Then it'd produce false alarms on the "WINDOWS" example i posted previously. It is inevitable that a deeper analysis that involves exploring both a fully constructed syntax tree and rich preprocessor information is necessary. Clang does provide such information, but probably the deeper analysis is not implemented beyond the "hmm there's a macro, let's silence the warning" level of ingenuity.

5

Yes, this is exactly right.

I think the fix here would be to try to make the silencing ask whether *everything* about the dead statement is a macro instantiation rather than *anything*.

John.