ConsenSysMesh / solidity-parser

Solidity Parser in Javascript
137 stars 53 forks source link

Normalize handling of BlockStatement brackets at FunctionBody node #58

Closed cgewecke closed 7 years ago

cgewecke commented 7 years ago

FunctionBody's type is BlockStatement but its parent consumes the enclosing brackets resulting in anomalous start / end values for the node. This is an issue for the Solium linter which wants to be able to analyze all BlockStatements in the same way.

The FunctionDeclaration rule was inherited from pegjs and it's not obvious why they chose to implement things this way. From the linter's perspective it puts relevant information in the wrong place.

@duaraghav8's solparse has revised the relevant rules so they work for his context here and here.

duaraghav8 commented 7 years ago

Thanks for opening this @cgewecke I and cgewecke discussed why I did this here (8. Start/end Position). So my fix was based on my interpretation of how the parser should have worked. And then I wrote Solium's code to comply with solparse's way of working. And now its heavily dependant on how solparse parses FunctionDeclaration & BlockStatement

Once we decide how the parser should finally work, I can change solium's code (if need be), but I think my version is how it should be.

Opinions?

ps- @raineorshine since you implemented the start / end position logic, maybe you too would like to give your input.

federicobond commented 7 years ago

Indeed, we should parse either BlockStatement or EOS as described in the official grammar.