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

Warn if shadowing built-ins #1637

Merged
merged 1 commit into from
Jul 26, 2017
Merged

Warn if shadowing built-ins #1637

merged 1 commit into from
Jul 26, 2017

Conversation

axic
Copy link
Member

@axic axic commented Feb 2, 2017

Fixes #1249.


for (Declaration const* declaration: m_globals)
if (declaration->name() == _function.name())
warning(_function.location(), "Shadowing global function \"" + _function.name() + "\".");
Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps it is better to say "Shadowing builtin function".

Copy link
Contributor

Choose a reason for hiding this comment

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

It does not have to be a function. What about builtin symbol?

Copy link
Member Author

@axic axic Feb 2, 2017

Choose a reason for hiding this comment

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

This is within visit(FunctionDefinition), but using builtin symbol for both cases is fine.

for (Declaration const* declaration: m_globals)
if (declaration->name() == _variable.name())
warning(_variable.location(), "Shadowing global variable \"" + _variable.name() + "\".");

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps it is better to say "Shadowing builtin variable".

@@ -49,6 +50,11 @@ void StaticAnalyzer::endVisit(ContractDefinition const&)
bool StaticAnalyzer::visit(FunctionDefinition const& _function)
{
m_nonPayablePublic = _function.isPublic() && !_function.isPayable();

for (Declaration const* declaration: m_globals)
Copy link
Member Author

Choose a reason for hiding this comment

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

@chriseth any idea why here m_globals.size() == 0, while in the constructor it is still 18?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe it was only a problem on my computer, it seems to work on AppVeyor.

@@ -93,7 +93,7 @@ parseAnalyseAndReturnError(string const& _source, bool _reportWarnings = false,
}
if (success)
{
StaticAnalyzer staticAnalyzer(errors);
StaticAnalyzer staticAnalyzer(globalContext->declartions(), errors);
Copy link
Contributor

Choose a reason for hiding this comment

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

declarations

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, there's still that other issue, at least on my computer.

@axic
Copy link
Member Author

axic commented Feb 2, 2017

Status: tests fail on Linux, but succeed on Windows.

@axic
Copy link
Member Author

axic commented Feb 6, 2017

No idea why the original vector<Declarations> didn't work on linux/mac, replaced with a vector<string> and now including this and super. Note: we could use the currentThis() and currentSuper() but that seems like an overkill.

@chriseth
Copy link
Contributor

chriseth commented Feb 7, 2017

Did you consider adding this code into NameAndTypeResolver.cpp? While perhaps conceptually less clean, it is much less error prone to add it there. We have the scopes, see what is visible where and so on. If we keep it as it is now and add a new declaration, we have to think about also adding it to the visitor here. As an example, you forgot to check for names of events :-)
Oh and what about import x as msg from "y.sol";?

@axic
Copy link
Member Author

axic commented Feb 7, 2017

Fixed the event and import case.

While perhaps conceptually less clean, it is much less error prone to add it there.

@chriseth Why should StaticAnalyzer exists in that case? :)

@chriseth
Copy link
Contributor

chriseth commented Feb 7, 2017

@axic it is not about static analyzer. The main design problem is that the scopes are not persisted in the AST annotations.

@axic
Copy link
Member Author

axic commented Feb 8, 2017

I'm not sure what is going on, for me it works on mac and linux (ubuntu), but travis fails at without any message:

Compiling ./scripts/../test/../std/StandardToken.sol...

@axic
Copy link
Member Author

axic commented Feb 8, 2017

The main design problem is that the scopes are not persisted in the AST annotations.

I think the scope issue which could affect this is members of a struct.

}
}
)";
CHECK_WARNING(text, "Shadowing builtin symbol");
Copy link
Member Author

Choose a reason for hiding this comment

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

Typo, this should be successful.

@chriseth
Copy link
Contributor

chriseth commented Feb 8, 2017

I think it is better to add this change to NameAndTypeResolver.cpp, basically to anything that callsDeclarationContainer::registerDeclaration(). It would be good to perhaps add it to that function itself, but it does not have access to the error list. At that point, we could also check for any shadowing. One thing we have to check there is whether overriding a function is implemented as shadowing.

BOOST_AUTO_TEST_CASE(shadowing_builtins_with_imports)
{
char const* text = R"(
import * as msg from "B.sol";
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps also add something like import {msg, block} as X from "B.sol" - that should also be fine.

Copy link
Member Author

Choose a reason for hiding this comment

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

Seems like that notation is broken currently:

Error: Expected "from".
               import {msg, block} as X from "B.sol"

Copy link
Member Author

Choose a reason for hiding this comment

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

Parser has this comment:

        // import "abc" [as x];
        // import * as x from "abc";
        // import {a as b, c} from "abc";

import {msg, block} from "B.sol"; works.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah right. I meant import * as X from "B.sol".

@axic axic force-pushed the warn-shadowing-globals branch 3 times, most recently from ac5e613 to 72fea3b Compare February 11, 2017 02:54
@axic axic changed the title Warn if shadowing built-ins [WIP] Warn if shadowing built-ins Feb 12, 2017
@axic
Copy link
Member Author

axic commented Mar 15, 2017

Rebased for good measure.

@axic
Copy link
Member Author

axic commented May 3, 2017

@roadriverrail would you be interested in looking into this?

@roadriverrail
Copy link
Contributor

@axic Yes, I'll look into this soon.

@roadriverrail
Copy link
Contributor

Similarly, I've gone ahead and done a rebase of this one, but I can't push to the repository. Once we get that sorted, I can take on the comments @chriseth left.

@roadriverrail
Copy link
Contributor

Just a quick ping before the weekly meeting...I had a rebase of this set up a couple weeks ago so that I could finish the work on it, but I can't push to the main solidity repo on this branch. If someone can please help me out with this, I can get this done. @chriseth @axic

@chriseth
Copy link
Contributor

@roadriverrail what is your progress on this? I would like to include this feature in the next version which can hopefully happen on monday.

@chriseth
Copy link
Contributor

We cannot really test imports inside this testing framework.

@axic
Copy link
Member Author

axic commented Jul 18, 2017

@chriseth is this ready? Needs to be rebased.

@axic axic changed the title [WIP] Warn if shadowing built-ins Warn if shadowing built-ins Jul 18, 2017
@chriseth
Copy link
Contributor

Yes, this is ready.

@axic
Copy link
Member Author

axic commented Jul 26, 2017

@chriseth you need to approve and merge

@chriseth chriseth merged commit 925569b into develop Jul 26, 2017
@axic axic deleted the warn-shadowing-globals branch July 26, 2017 15:53
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.

None yet

4 participants