Skip to content
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

Closed
jruderman opened this issue Feb 23, 2012 · 11 comments
Closed

Unreachable outer expressions should warn #1889

jruderman opened this issue Feb 23, 2012 · 11 comments
Labels
A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@jruderman
Copy link
Contributor

fn bye() -> ! { fail }

fn warns() { bye(); log(error, 3); }

fn does_not_warn() { log(error, bye()); }
@ghost ghost assigned catamorphism Apr 13, 2012
@catamorphism
Copy link
Contributor

@jruderman I think the current behavior is correct. All of the statements in does_not_warn are reachable (there's only one statement). It happens to be the case that the statement always terminates abnormally, but the reachability analysis doesn't warn about that, only about statements that aren't reachable at all.

If you disagree, can you elaborate?

@jruderman
Copy link
Contributor Author

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?

@catamorphism
Copy link
Contributor

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.

@graydon
Copy link
Contributor

graydon commented Apr 19, 2012

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?

@graydon
Copy link
Contributor

graydon commented Apr 24, 2013

switched milestone

@pcwalton
Copy link
Contributor

I don't believe this is backwards incompatible, renominating.

@graydon
Copy link
Contributor

graydon commented May 30, 2013

just a bug, removing milestone/nomination.

@emberian
Copy link
Member

Visiting for triage. FWIW, I agree with OP

@huonw
Copy link
Member

huonw commented Sep 30, 2013

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 bar(foo()) as similar to let r = foo(); bar(r); as possible seems like reasonable goal.

@emberian
Copy link
Member

Visiting again for triage.

@steveklabnik
Copy link
Member

Triage: current code:

fn bye() -> ! { panic!() }

fn warns() { bye(); 1 + 1; }

fn does_not_warn() { 1 + bye(); }

fn main() {}

current warnings:

hello.rs:1:1: 1:27 warning: function is never used: `bye`, #[warn(dead_code)] on by default
hello.rs:1 fn bye() -> ! { panic!() }
           ^~~~~~~~~~~~~~~~~~~~~~~~~~
hello.rs:3:1: 3:29 warning: function is never used: `warns`, #[warn(dead_code)] on by default
hello.rs:3 fn warns() { bye(); 1 + 1; }
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
hello.rs:3:21: 3:27 warning: unreachable statement, #[warn(unreachable_code)] on by default
hello.rs:3 fn warns() { bye(); 1 + 1; }
                               ^~~~~~
hello.rs:5:1: 5:34 warning: function is never used: `does_not_warn`, #[warn(dead_code)] on by default
hello.rs:5 fn does_not_warn() { 1 + bye(); }
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

7 participants