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

(Seemingly) irrelevant data being created #56

Closed
duaraghav8 opened this issue Jan 5, 2017 · 3 comments
Closed

(Seemingly) irrelevant data being created #56

duaraghav8 opened this issue Jan 5, 2017 · 3 comments

Comments

@duaraghav8
Copy link
Contributor

duaraghav8 commented Jan 5, 2017

Code:

contract Foo {
    bytes32 x;
}

sp.parse (code).body [0] yields:

{
  "type": "ContractStatement",
  "name": "Full",
  "is": [],
  "body": [
    [
      {
        "type": "DeclarativeExpression",
        "name": "x",
        "literal": {
          "type": "Type",
          "literal": "bytes32",
          "members": [],
          "array_parts": [],
          "start": 15,
          "end": 22
        },
        "is_constant": false,
        "is_public": false,
        "is_private": false,
        "is_internal": false,
        "is_storage": false,
        "is_memory": false,
        "start": 15,
        "end": 24
      },
      [],
      [
        [],
        ";"
      ]
    ]
  ],
  "start": 0,
  "end": 26
}

Observer the body of the ContractStatement (first object is DeclarativeExpression, which is fine. But what's happening after this?). Its taking semicolon as a separate entity, whereas the semicolon, together with an expression before that, make ExpressionStatement.

My fix in solparse creates the following structure:

{
  "type": "ContractStatement",
  "name": "Full",
  "is": [],
  "body": [
    {
      "type": "ExpressionStatement",
      "expression": {
        "type": "DeclarativeExpression",
        "name": "x",
        "literal": {
          "type": "Type",
          "literal": "bytes32",
          "members": [],
          "array_parts": [],
          "start": 15,
          "end": 22
        },
        "is_constant": false,
        "is_public": false,
        "is_private": false,
        "is_internal": false,
        "is_memory": false,
        "start": 15,
        "end": 24
      },
      "start": 15,
      "end": 25
    }
  ],
  "start": 0,
  "end": 26
}

@cgewecke is working on moving all fixes in solparse to solidity-parser. Please comment on the structure elicited by solparse above, so we can finalize.

@cgewecke
Copy link
Contributor

cgewecke commented Jan 5, 2017

@duaraghav8 What did you change in solidity-parser to get the solparse output?

@duaraghav8
Copy link
Contributor Author

@federicobond
Copy link
Contributor

OK, the problem is caused by this rule:

SourceElement
  = AssignmentExpression __ EOS
  / DeclarativeExpression __ EOS
  / EnumDeclaration
  ... 

Those first two rules do not parse to AssignmentExpression or DeclarativeExpression nodes but to arrays with the whitespace and EOS result as items too.

I propose to define StateVariableDeclaration as this:

StateVariableDeclaration
  = declaration:(AssignmentExpression / DeclarativeExpression) __ EOS
  {
    // Do some node manipulation here
  }

And replace it in the SourceElement rule, which would also bring the parser more in line with the official grammar.

The problem is that the layout for the AssignmentExpression and DeclarativeExpression are very different. AssignmentExpression has left, right and operator keys, where left is a DeclarativeExpression. StateVariableDeclaration should return a node with a consistent layout.
Since operator does not make sense in this context, perhaps value should be the key containing the right-hand side expression for this node.

What do you think?

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

No branches or pull requests

3 participants