Closed cgewecke closed 7 years ago
This looks good, but I wonder wether it's better to make the resulting AST compatible with positional arguments, so that tools don't have to implement named arguments support separately.
What do you think?
Oh yes, that's a good suggestion. Do you think it's worth trying to preserve the name?
For example NameValueAssignment
could be rewritten:
NameValueAssignment
= id:Identifier __ ":" __ value:AssignmentExpression __ {
value.argName = id.name;
return value;
}
Sorry, I have been thinking more about this and now I am not so sure. If we just discarded the start and end positions of the identifiers from the resulting AST we would be losing too much information.
A fairly obvious use case for them is a linter highlighting the argument name because there are no fields named that way, or suggesting the possibility of a typo because a similar name is present in the original struct definition.
Now I am more inclined to keep this as is and just rename id
to name
so that the resulting NameValueAssignment
actually has both name
and value
properties.
Of course, we could embed the whole Identifier
node inside the Expression
node under the argName
key as you suggested, but it would look quite weird.
Ok cool that makes sense. I'll push the id/name change in a sec. Thanks Federico.
When I rewrote my final comment I forgot to mention also using the whole Identifier node as the value for the name key. I am going to amend it and merge it manually.
Done. Commit is still attributed to you. Thanks @cgewecke!
👍
This PR addresses #71, where SP throws an error when instantiating a
struct
as below:The relevant part of the Solidity grammar looks like this:
doc_examples.sol