Sorry for another PR so soon; I just realized that the yecc grammar I had provided in my previous PR doesn't parse function signatures with function names like fooBar() or foo_bar() or foo_uint256() (or B() or 3() or uint256(), which are also all—surprisingly—syntactically valid per spec).
This PR fixes that (and adds a doctest to assert that such a function signature decodes successfully.)
Fixing this problem, though, uncovers a second problem: the grammar as I wrote it contains an inherent parsing conflict (e.g. the plain string uint256 is—without the context of items not yet on the parser's stack—either a type or an identifier.) This is only a problem when ABI.Parser.parse!/2 is called without a type expectation (i.e. the form used for ABI.encode/1 and ABI.decode/1), causing it to try to consume either a type or a selector.
I resolved this second problem by changing out the type clause for a tuple clause in the parser's implicit entrypoint. This also, conveniently, more tightly bounds possible outputs to the expectations of ABI.encode/1 and ABI.decode/1. General type parsing is still available by explicitly passing as: :type to parse!/2, as done in ABI.FunctionSelector.decode_type/1.
Sorry for another PR so soon; I just realized that the yecc grammar I had provided in my previous PR doesn't parse function signatures with function names like
fooBar()orfoo_bar()orfoo_uint256()(orB()or3()oruint256(), which are also all—surprisingly—syntactically valid per spec).This PR fixes that (and adds a doctest to assert that such a function signature decodes successfully.)
Fixing this problem, though, uncovers a second problem: the grammar as I wrote it contains an inherent parsing conflict (e.g. the plain string
uint256is—without the context of items not yet on the parser's stack—either atypeor anidentifier.) This is only a problem whenABI.Parser.parse!/2is called without a type expectation (i.e. the form used forABI.encode/1andABI.decode/1), causing it to try to consume either atypeor aselector.I resolved this second problem by changing out the
typeclause for atupleclause in the parser's implicit entrypoint. This also, conveniently, more tightly bounds possible outputs to the expectations ofABI.encode/1andABI.decode/1. Generaltypeparsing is still available by explicitly passingas: :typetoparse!/2, as done inABI.FunctionSelector.decode_type/1.