-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Unreachable outer expressions should warn #1889
Comments
@jruderman I think the current behavior is correct. All of the statements in If you disagree, can you elaborate? |
I feel like "statement with parts that are never evaluated" is roughly equivalent to "sequence of statements, some of which are never evaluated". It's strange that only the latter warns. What's special about separate statements? |
We're approximating an undecidable problem here, so where we draw the line is always going to be arbitrary. Since it's always going to be an approximation, we're focusing on catching the most likely mistakes. It's my feeling that "unreachable statement" reflects an error that's common for people to make (I know I've hit that error while writing code), whereas "unreachable subexpression" is less common, especially in an imperative language. But I'm happy to hear other opinions. |
Seems to me like we ought to be able to calculate this. Or rather, seems to me like we already are, or ought to be, since it's part of the CFG. Is it just a matter of figuring out how to emit a warning? |
switched milestone |
I don't believe this is backwards incompatible, renominating. |
just a bug, removing milestone/nomination. |
Visiting for triage. FWIW, I agree with OP |
triage: still an issue, updated example: fn bye() -> ! { fail!() }
fn warns() { bye(); 1 + 1; }
fn does_not_warn() { 1 + bye(); } I don't have a particular opinion, although having |
Visiting again for triage. |
Triage: current code:
current warnings:
|
The text was updated successfully, but these errors were encountered: