issue w/ "success"

[mattiaerre]

as per @maxsam4 comment on Gitter:

[the plugin] prettifies (success, ) to (success) which is incorrect.

[mattiaerre]

example:

pragma solidity ^0.5.0;

contract demo {
    function hello() public view returns(bool,bool) {}
}

contract demo2 {
    function world(address payable _yo) public view {
        bool yo;
        (yo, ) = demo(_yo).hello();
    }
}

[mattiaerre]

check this issue: federicobond/solidity-parser-antlr#43

// cc @fvictorio

[federicobond]

Apparently, Solidity is taking a one-dimensional tuple in the left side and somehow making it work for a bigger dimension in the right side. If you can work around the issue by walking through that source code slice and making sense of the position of commas I would suggest you to that for the time being 😕

[mattiaerre]

so @federicobond you are suggesting to find an alternative solution outside the parser? does the AST keep that info somewhere or we should refer back to the source code?

// cc @fvictorio

[federicobond]

Yes, as far as I understand the AST for (a,) is the same as (a). Refer to the source code to disambiguate the two.

[maxsam4]

Yes, as far as I understand the AST for (a,) is the same as (a). Refer to the source code to disambiguate the two.

The AST generated by solc does differentiate between (a, ) and (a). For example
The relevant part of ast for (yo, yo) looks like

"leftHandSide": {
    "argumentTypes": null,
    "components": [
        {
            "argumentTypes": null,
            "id": 50,
            "name": "yo",
            "nodeType": "Identifier",
            "overloadedDeclarations": [],
            "referencedDeclaration": 22,
            "src": "357:2:0",
            "typeDescriptions": {
                "typeIdentifier": "t_bool",
                "typeString": "bool"
            }
        },
        {
            "argumentTypes": null,
            "id": 51,
            "name": "yo",
            "nodeType": "Identifier",
            "overloadedDeclarations": [],
            "referencedDeclaration": 22,
            "src": "361:2:0",
            "typeDescriptions": {
                "typeIdentifier": "t_bool",
                "typeString": "bool"
            }
        }
    ],
    "id": 52,
    "isConstant": false,
    "isInlineArray": false,
    "isLValue": true,
    "isPure": false,
    "lValueRequested": true,
    "nodeType": "TupleExpression",
    "src": "356:8:0",
    "typeDescriptions": {
        "typeIdentifier": "t_tuple$_t_bool_$_t_bool_$",
        "typeString": "tuple(bool,bool)"
    }
}

The relevant part of ast for (yo, ) looks like

"leftHandSide": {
    "argumentTypes": null,
    "components": [
    {
        "argumentTypes": null,
        "id": 32,
        "name": "yo",
        "nodeType": "Identifier",
        "overloadedDeclarations": [],
        "referencedDeclaration": 22,
        "src": "285:2:0",
        "typeDescriptions": {
            "typeIdentifier": "t_bool",
            "typeString": "bool"
        }
    },
    null
],
    "id": 33,
    "isConstant": false,
    "isInlineArray": false,
    "isLValue": true,
    "isPure": false,
    "lValueRequested": true,
    "nodeType": "TupleExpression",
    "src": "284:6:0",
    "typeDescriptions": {
        "typeIdentifier": "t_tuple$_t_bool_$__$",
        "typeString": "tuple(bool,)"
    }
}

The relevant ast for yo looks like

"leftHandSide": {
    "argumentTypes": null,
    "id": 24,
    "name": "yo",
    "nodeType": "Identifier",
    "overloadedDeclarations": [],
    "referencedDeclaration": 22,
    "src": "251:2:0",
    "typeDescriptions": {
        "typeIdentifier": "t_bool",
        "typeString": "bool"
    }
}

Edit: federicobond/solidity-parser-antlr#44 can be used as a temporary fix.

[maxsam4]

Also, (, yo) in (, yo) = demo(_yo).hello(); breakes the prettier.

Edit: Simple fix by #106

[federicobond]

Just released a new version of the parser (0.4.0) that helps solve this issue. Let me know if you find anything else.

[maxsam4]

I updated the plugin to use the latest parser and tests broke. Turns out there was another bug in the plugin. The snapshots in the tests were also broken so essentially they were checking that plugin returns an invalid result. Pushing a PR to fix it now.

[mattiaerre]

thanks so much for this @maxsam4 and @federicobond
I'll look into #106 asap