-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty statement "can never be reached" #295
Comments
Let's see. I rewrote that warning (and dead-code stripping) in 6.40, but the problem here goes back to 6.31, probably farther. For simplicity I'm reducing the example to this:
|
I think it's reasoning incorrectly about the
...then the warning persists. But if you remove the I'd say for now rewrite the ParseNoun() function in this way. I may be able to improve this in a future release, but it's not a high priority. The warning logic is a big fussy mess and it would be easy to break some cases while fixing others. |
The warning occurs on the "jump to top of loop" opcode (i.e. states.c:1745, etc) if it's impossible for execution to reach the end of the loop body. This is a simpler example:
It may be sufficient to put an |
The compiler issues "This statement can never be reached" warnings for the above code, pointing at the ending brace for the while loops (which I marked in red). It seems like this warning is issued during assembly output, so presumably it outputs the end-of-loop jump back to the top of the loop after the unconditional jump out of the loop, and that is what it is warning on.
But in practical terms, it looks like it is issuing a warning for the white space prior to the end of the loop. And there's no way to suppress that useless warning without suppressing otherwise useful warnings about unreachable code.
Related to #87, in that I imagine the optimizations that come out of that thread would indirectly solve this issue.
The text was updated successfully, but these errors were encountered: