[solidity] Ambiguity in solidity grammar

[kaby76]

This is a note on the ambiguity of the Solidity grammar, initially started in a conversation in #4257. As the grammar in the PR mirrors that from the official repository grammar, I will assume the grammar here:

SolidityLexer.g4.txt
SolidityParser.g4.txt

Ambiguity with voters[to].delegate != address(0)

See ex2.sol.txt, line 91.

This is ambiguous because there are two parses, one with the (0) associated with address, the other associated with voters[to].delegate != address. One thing I do notice are the alts | <assoc = right> expression assignOp expression, | expression callArgumentList , | Payable callArgumentList. These are classic mistakes--you cannot "hide" the operators behind a non-terminal!

The fix is to simply unfold the symbol callArgumentList in the two alts it is used in expression. (I.e., paste the RHS of the callArgumentList where the symbol occurs in `expression.)

https://github.com/codeFather2/grammars-v4/blob/45afcb5b79380bb5aec4add590328a777b730685/solidity/SolidityParser.g4#L460-L461

Ambiguity with new uint64[](3)

See test.sol.txt, line 409

There are two possible parses for new uint64[](3). One is to associate the [] with typeName as new (uint64[]). The other is to associate the expression new uint64, as (new uint64)[]. Obviously, the expression precedence is supposed to be the former.

In addition, is the constructor called here supposed to have a parameter indicating the length? Unfortunately, the parse tree is:

        expression
         expression
          Attribute Skip Value ' '
          New
           "new"
          typeName
           typeName
            elementaryTypeName
             Attribute Skip Value ' '
             UnsignedIntegerType
              "uint64"
           LBrack
            "["
           RBrack
            "]"
         callArgumentList
          LParen
           "("
          expression
           literal
            numberLiteral
             DecimalNumber
              "3"
          RParen
           ")"

This seems incorrect because the "new" is a constructor and "3" is being passed to it.

Ambiguity with $allocate(0x20)

See See test.sol.txt, line 475.

$allocate)0x20) can be parsed as:

../examples/test.sol.126:              yulExpression
../examples/test.sol.126:               yulFunctionCall
../examples/test.sol.126:                Attribute Skip Value ' '
../examples/test.sol.126:                YulIdentifier
../examples/test.sol.126:                 "$allocate"
../examples/test.sol.126:                YulLParen
../examples/test.sol.126:                 "("
../examples/test.sol.126:                yulExpression
../examples/test.sol.126:                 yulLiteral
../examples/test.sol.126:                  YulHexNumber
../examples/test.sol.126:                   "0x20"
../examples/test.sol.126:                YulRParen
../examples/test.sol.126:                 ")"

or

../examples/test.sol.126:              yulFunctionCall
../examples/test.sol.126:               Attribute Skip Value ' '
../examples/test.sol.126:               YulIdentifier
../examples/test.sol.126:                "$allocate"
../examples/test.sol.126:               YulLParen
../examples/test.sol.126:                "("
../examples/test.sol.126:               yulExpression
../examples/test.sol.126:                yulLiteral
../examples/test.sol.126:                 YulHexNumber
../examples/test.sol.126:                  "0x20"
../examples/test.sol.126:               YulRParen
../examples/test.sol.126:                ")"

The problem is, of course, yul-variable-declaration: https://docs.soliditylang.org/en/latest/grammar.html#a4.SolidityParser.yulVariableDeclaration

Either all applies because they derive the same thing.