Changing Alex/Happy parser to a megaparsec-based one

[rodrigogribeiro]

• Added test cases for the parser
• Changing the syntax of ternary expression to usual C syntax, since megaparsec allows backtracking parsers.

[mbenke]

Forgotten semicolon in a class declaration leads to slightly misleading error message:

forall t.class t:Catenable {
  function cat(x:t) -> memory(bytes) 
}

<input>:7:3:
  |
7 |   function cat(x:t) -> memory(bytes) 
  |   ^
unexpected 'f'
expecting '}'

[mbenke]

This parses in a weird way (it's a parse error on main):

contract Pars {
function main() -> (){  let f:word; 42(); }
}

yields

$ esolc tmp/pars.solc  -g -s --dump-ast
tmp/pars.solc
> AST after name resolution for /home/ben/work/review/tmp/pars.solc
contract Pars {
   constructor () {
   }
   function main () -> () {
      let f : word ;
      42;
      ();
   }
}

[rodrigogribeiro]

contract Pars {
function main() -> (){ let f:word; 42(); }
}

It's weird because the same code piece returned:

contract Pars {
   function main () -> () {
      let f : word ;
      42;
      ();
   }
}

[rodrigogribeiro]

Forgotten semicolon in a class declaration leads to slightly misleading error message:

forall t.class t:Catenable {
  function cat(x:t) -> memory(bytes) 
}

<input>:7:3:
  |
7 |   function cat(x:t) -> memory(bytes) 
  |   ^
unexpected 'f'
expecting '}'

I've fixed it by improving the error message locally for signatures in class definitions. Now, it returns:

<input>:3:1:
  |
3 | }
  | ^
unexpected '}'
expecting "->" or ';' after function signature

[mbenke]

I think I understand the weird 42() behaviour now:

exprOrAssignP = do
  lhs <- expP
  choice
    [ do rhs <- equalsP *> expP; _ <- semicolon; return (Assign lhs rhs),
      do rhs <- symbol "+=" *> expP; _ <- semicolon; return (StmtPlusEq lhs rhs),
      do rhs <- symbol "-=" *> expP; _ <- semicolon; return (StmtMinusEq lhs rhs),
      StmtExp lhs <$ optional semicolon
    ]

The semicolon is optional so 42() gets parsed the same as 42; ();
This is probably done to parse Rust-like f(x:word) -> word { x+1 } right?

Perhaps we should change the syntax to f(x:word) -> word = x+1?

[mbenke]

Might be easier to read if they are sorted alphabetically

[mbenke]

This should be abstracted out and named to avoid repetitions and improve readability. Ditto for subsequent 'do's in importP

[mbenke]

why is this needed? doesn't lexeme, hence also identifier consume space?

[mbenke]

Well done, the suggestions are mostly code golf, feel free to ignore the ones you do not like and keep the ones you do.

The 42() corner case is probably not worth the effort now, but worth keeping in mind when we redesign the syntax.

Once #415 is merged, it will need to be reflected in the new parser.

[rodrigogribeiro]

The semicolon is optional so 42() gets parsed the same as 42; (); This is probably done to parse Rust-like f(x:word) -> word { x+1 } right?

Exactly!

Perhaps we should change the syntax to f(x:word) -> word = x+1?

We could discuss when deciding the language syntax.