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

Enforce data location. #4738

Merged
merged 7 commits into from
Aug 14, 2018
Merged

Enforce data location. #4738

merged 7 commits into from
Aug 14, 2018

Conversation

chriseth
Copy link
Contributor

@chriseth chriseth commented Aug 7, 2018

Fixes #4382
Fixes #1815

@@ -297,7 +297,7 @@ bool NameAndTypeResolver::resolveNamesAndTypesInternal(ASTNode& _node, bool _res
if (!resolveNamesAndTypes(*node, false))
{
success = false;
break;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure why this was here. I will run the whole test suite once the expectations are all updated, if it does not crash, I would propose to keep it like this.

@axic
Copy link
Member

axic commented Aug 7, 2018

Needs rebasing.

@codecov
Copy link

codecov bot commented Aug 7, 2018

Codecov Report

Merging #4738 into develop will decrease coverage by 0.01%.
The diff coverage is 85.6%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #4738      +/-   ##
===========================================
- Coverage    87.79%   87.77%   -0.02%     
===========================================
  Files          314      314              
  Lines        31107    31159      +52     
  Branches      3690     3688       -2     
===========================================
+ Hits         27310    27351      +41     
- Misses        2548     2552       +4     
- Partials      1249     1256       +7
Flag Coverage Δ
#all 87.77% <85.6%> (-0.02%) ⬇️
#syntax 28.41% <84%> (+0.08%) ⬆️

@@ -297,6 +303,9 @@ void ReferencesResolver::endVisit(VariableDeclaration const& _variable)
if (_variable.annotation().type)
return;

if (_variable.isConstant() && !_variable.isStateVariable())
m_errorReporter.declarationError(_variable.location(), "The \"constant\" keyword can only be used for state variables.");
Copy link
Member

Choose a reason for hiding this comment

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

Is this actually part of this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Previously, the checks were much less restrictive, so the checks would pass here and then the type checker did the rest, but I actually think it is better to have strict tests here and then also move this check here, which I would say is the appropriate place.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok perhaps to summarize differently: Other ways to solve this would result in weird error messages.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, to me it seems this check should even be moved up to the SyntaxChecker instead. Using the constant keyword in the wrong place feels like a syntax error to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you agree, I would still like to keep it here. While it can be checked earlier, I think it still "belongs" here, especially when we also add things like mutable and immutable.

Copy link
Member

Choose a reason for hiding this comment

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

I'm fine with keeping it here.

@@ -708,8 +708,6 @@ bool TypeChecker::visit(VariableDeclaration const& _variable)
expectType(*_variable.value(), *varType);
if (_variable.isConstant())
{
if (!_variable.isStateVariable())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the place where the constant check was previously.

return;
}

if (_typeName.isPayable() && _typeName.visibility() != VariableDeclaration::Visibility::External)
{
typeError(_typeName.location(), "Only external function types can be payable.");
fatalTypeError(_typeName.location(), "Only external function types can be payable.");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These have to be fatal because otherwise the constructor of FunctionType will assert.

"Location has to be calldata for external functions "
"(remove the \"memory\" or \"storage\" keyword)."
);
case Location::Memory:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could be pulled up onto the same line and unindented once.

@@ -454,3 +432,21 @@ void ReferencesResolver::fatalDeclarationError(SourceLocation const& _location,
m_errorOccurred = true;
m_errorReporter.fatalDeclarationError(_location, _description);
}

DataLocation ReferencesResolver::variableLocationToDataLocation(VariableDeclaration::Location _varLoc)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is unused, should either be used above or removed.

if (!hasReferenceOrMappingType() || isStateVariable())
return set<Location>{ Location::Default };

if (isEventParameter())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

change to else if

}
else if (isLocalVariable())
{
// TODO where was this checked in the previous version?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

remove - it was in reference resolver visit.

@@ -100,7 +100,7 @@
{
"constant" : false,
"name" : "",
"scope" : 16,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for adding this to isoltest, @ekpyron ;)

Copy link
Member

Choose a reason for hiding this comment

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

Although it's still a bit hacky, e.g. it's adding the // ---- delimiter above, although it's not needed for ASTJSON tests - but I'll fix all that in 0.5.1.

@@ -0,0 +1,11 @@
library L {
struct Nested { uint y; }
// data location specifier in function signature should be optional even if there are multiple choices
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Remove comment and also extract the working case.

@@ -0,0 +1,9 @@
contract C {
// Warning for no data location provided can be silenced with storage or memory.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

remove

@@ -0,0 +1,7 @@
contract C {
// Shows that the warning for no data location provided can be silenced with storage or memory.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

remove

@chriseth chriseth mentioned this pull request Aug 8, 2018
29 tasks
Copy link
Member

@ekpyron ekpyron left a comment

Choose a reason for hiding this comment

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

Only had a very quick look so far, so for now only two very minor comments.

if (isReturnParameter())
return true;

std::vector<ASTPointer<VariableDeclaration>> const* parameters = nullptr;
Copy link
Member

Choose a reason for hiding this comment

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

No need for std::.

return false;
if (callable->returnParameterList())
for (auto const& variable: callable->returnParameterList()->parameters())
std::vector<ASTPointer<VariableDeclaration>> const* returnParameters = nullptr;
Copy link
Member

Choose a reason for hiding this comment

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

std:: again

@ekpyron
Copy link
Member

ekpyron commented Aug 14, 2018

Emscripten build fails on travis.
Either we need #include <iterator> in StringUtils.h or the older emscripten is not fully C++11 compatible - which the latter would be another reason for #4486, it seems to work on circleci.

@chriseth
Copy link
Contributor Author

Actually I think that is an argument against using the same version.

@ekpyron
Copy link
Member

ekpyron commented Aug 14, 2018

That depends on whether it's the lack of a header include or the lack of C++11 support... If it's the former, then yes, if it's the latter, then bumping the minimum required version makes more sense, I would say.

@chriseth
Copy link
Contributor Author

Only read half-way into this, but the problem may be that transformed only gets us a single-pass iterator, while std::next requires a forward iterator.

@chriseth
Copy link
Contributor Author

Not sure why it works in the other cases, but interestingly, since C++17, there is also an input iterator version of std::next...

@ekpyron
Copy link
Member

ekpyron commented Aug 14, 2018

That's probably right - and I guess newer compiler (resp. STL) versions are forward compatible with C++17, for which std::next only requires an input iterator. In that sense maybe it is an argument against #4486.

@chriseth
Copy link
Contributor Author

Updated, let's see what travis will do with it.

@chriseth
Copy link
Contributor Author

Build passed.

@ekpyron
Copy link
Member

ekpyron commented Aug 14, 2018

Why are the circleci linux tests passing and there is a test failure for one of the appveyor builds? Not related to this PR, but weird.

@ekpyron
Copy link
Member

ekpyron commented Aug 14, 2018

It's actually very weird - the respective test case syntaxTests/conversion/conversion_to_bytes.sol is not actually in this branch - not sure how it ended up in the appveyor test run, but in any case, the test is in develop and will fail after this PR, if the expectations are not updated, so this PR needs to be rebased again.

@chriseth
Copy link
Contributor Author

Yeah, it sometimes happens that appveyor picks the wrong commit.

ekpyron
ekpyron previously approved these changes Aug 14, 2018
@chriseth
Copy link
Contributor Author

Another run...

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.

5 participants