Skip to content

Warn about unreachable code. #5765

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

Merged
merged 1 commit into from
Jan 10, 2019
Merged

Warn about unreachable code. #5765

merged 1 commit into from
Jan 10, 2019

Conversation

ekpyron
Copy link
Member

@ekpyron ekpyron commented Jan 9, 2019

Closes #2340.

This still does not consider constant conditions (e.g. if (false) ...). I would only add support for that, once we have a full solidity-level compile-time constant expression evaluator, though (which at least I would say we should have).

@ekpyron ekpyron requested a review from chriseth January 9, 2019 05:46
@ekpyron ekpyron changed the title Warn about unreachable code. [WIP] Warn about unreachable code. Jan 9, 2019
@ekpyron ekpyron changed the title [WIP] Warn about unreachable code. Warn about unreachable code. Jan 9, 2019
@codecov

This comment has been minimized.

@codecov

This comment has been minimized.

@chriseth
Copy link
Contributor

chriseth commented Jan 9, 2019

I guess this logic does not detect that e.g. a function always reverts, and thus calls to that function will have similar semantics to revert(), right?
We might want to add that (in a subsequent feature) so that the warning is as powerful for code that implements helper functions for revert.

@chriseth
Copy link
Contributor

chriseth commented Jan 9, 2019

Another question to discuss: Do we want to make this an error?

@ekpyron
Copy link
Member Author

ekpyron commented Jan 9, 2019

I think this is too fragile to make an error (because of the if (false)-like cases... detection won't be perfect in all cases). Actually those are all false negatives... hm... I have to think about it.

Function calls are basically ignored in the CFG so far, but yes, we can change that in the future (out of scope for now I would say, though).

@ekpyron
Copy link
Member Author

ekpyron commented Jan 9, 2019

I think we could make this an error, if we want to. But to me it seems a warning would suffice... we could remove the dead code ourselves during optimization.

@axic
Copy link
Member

axic commented Jan 9, 2019

Nice!

@ekpyron
Copy link
Member Author

ekpyron commented Jan 9, 2019

Should be squashed before merging.

@stackenbotten

This comment has been minimized.

@stackenbotten

This comment has been minimized.

@stackenbotten

This comment has been minimized.

@stackenbotten

This comment has been minimized.

@ekpyron ekpyron force-pushed the unreachableCode branch 3 times, most recently from fee0a2b to 3faf44f Compare January 9, 2019 15:55
Copy link
Contributor

@chriseth chriseth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine apart from the small changes. Also, should this be squashed to a single commit?

@ekpyron ekpyron dismissed chriseth’s stale review January 9, 2019 16:39

Tried to address the small changes and squashed to one commit.

@chriseth chriseth merged commit 950e193 into develop Jan 10, 2019
@ekpyron ekpyron deleted the unreachableCode branch January 10, 2019 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants