GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
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
Warn about side-effect free statements.
Please check that this change is correct. This is the difference between f and f(). The first should be pure even if f is not a pure function.
Why is this just for functions? What about other magic variables?
For instance, msg might be pure although msg.sender is not pure.
Sure, but do we really need that? When we do the follow-up story, we can add a positive and a negative list and error whenever both are set to "false".
I don't think positives or negatives are relevant. I'm seeing only booleans. If an expression reads, and if an expression writes.
We can also do this in the follow-up. In that case, I'll add this point in the follow-up issue.
Can you add a test for var a = revert; a; ?
var a = revert; a;
@axic such a test would be identical to uint a; a;, but I'll add it.
uint a; a;
Change error message.
@axic it turns out such code will not trigger the warning, because a is not considered pure by the current code - it could be changed in a loop or so. I guess we will still catch most of the cases.
Note that this is not detecting all cases of side-effect-free statements, the rest will be done in #1380
Do we have an issue to warn about unread variables?
Yes, someone else is working on it already.
Is this a pure statement?
No it is not.
but the true is.
Will you add a test about for (uint x = 0; true; x++)?
for (uint x = 0; true; x++)
Added the test.
Test for side-effect free condition.
Looks good to me. I'm restarting the emscripten test.
I know it is useless because they are regular functions, but would it make sense having a test for all the critical ones (revert, assert, require, selfdestruct)? Just in case some other future feature would mess them up.
More pure tests.
Added the tests.
Travis was a sporadic single failure, windows error was race condition with bytecode upload.
@chriseth can there be an issue about the race condition?