Bug 13858 – Wrong warning about unreachable code with break/goto case
Status
RESOLVED
Resolution
FIXED
Severity
minor
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-12-12T09:07:00Z
Last change time
2015-06-09T05:11:38Z
Keywords
industry, rejects-valid
Assigned to
nobody
Creator
andrej.mitrovich
Comments
Comment #0 by andrej.mitrovich — 2014-12-12T09:07:05Z
-----
void foo() { assert(0); }
void main()
{
int x = 0;
LSwitch: switch (x)
{
case 0:
break LSwitch;
default: return;
}
foo();
}
-----
$ dmd -w -run test.d
> test.d(15): Warning: statement is not reachable
However the above isn't true:
$ dmd -run test.d
> [email protected](1): Assertion failure
Comment #1 by andrej.mitrovich — 2014-12-12T09:08:06Z
Also, the same thing happens with 'goto', although I'm not sure whether there's a semantic difference between the two (I assume so).
Comment #2 by public — 2014-12-15T06:26:01Z
Affects both D1 and D2
Comment #3 by yebblies — 2015-01-24T09:52:42Z
(In reply to Andrej Mitrovic from comment #1)
> Also, the same thing happens with 'goto', although I'm not sure whether
> there's a semantic difference between the two (I assume so).
If by that you mean replacing the 'break LSwitch' with 'goto LSwitch' then the warning is correct, because that would be an infinite loop.
The problem here is that LabelStatement::blockExit just returns the blockExit of the labeled statement, and isn't really designed for handling a label containing a goto to itself.
BreakStatement::blockExit produces BEgoto when used with a label, but this is overly vague, as labeled breaking from a switch should produce BEfallthru.
I tried changing SwitchStatement::blockExit to treat an internal BEgoto as BEfallthrough, like ForStatement does, but it seems to also use BEgoto to indicate internal 'goto case's and that change leads to false positive "no return exp; or assert(0)" errors.
I'm not sure it's possible to fix this without properly building and walking a CFG, maybe somebody else knows for sure.
Comment #4 by public — 2015-01-24T15:16:48Z
I'll mark it as "hard to fix, better use workaround" then :)
Comment #5 by github-bugzilla — 2015-01-25T09:02:43Z