-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for multiple (named) return parameters in Natspec devdoc #7534
Add support for multiple (named) return parameters in Natspec devdoc #7534
Conversation
2a14c7a
to
a97e996
Compare
" \"a\": \"Documentation for the first parameter starts here. Since it's a really complicated parameter we need 2 lines\",\n" | ||
" \"second\": \"Documentation for the second parameter\"\n" | ||
" },\n" | ||
" \"return\": \"The result of the multiplicationAnd cookies with nutella\"\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to change as well such that return
always contains at least one key-value-pair for each return parameter. Since they don't have a name in this test, we could think about adding a unique placeholder for each parameter:
"return": {
"_1": "The result of the multiplication",
"_2": "And cookies with nutella"
},
If the parameter has a name it could use that as the key.
I think we can't check if the documentation contains the name of the parameter (as we do for function parameters) since they are allowed to have no name (the compiler allows function parameters to don't have a name, but NatSpec doesn't).
/// @return The result of the multiplication | ||
/// @return And cookies with nutella | ||
function mul(uint a, uint second) public returns (uint, uint) { | ||
uint mul = a * 7; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation is off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to revisit the concept again. E.g. We should also take the first word of the line and check if this corresponds to named return parameter, if any. If return parameters don't have a name, this check should be ignored.
Please also add a Changelog entry since this is a user-facing change that will effect tools. |
Would it make sense to have this method perform that check and throw an error? It might be cleaner to reuse the current logic in the doc parser for |
@Gh1dra Yes, I think we should use the same logic as we do for function parameters. And yes, you're right. This would break existing contracts that use named return parameters (and that probably do not use the parameter name as the first word). But since the current behaviour is broken, I'd tend to properly clean it up and include this PR in our next breaking release, which will be 0.6.0. |
The failing macOS build ( |
fcf1990
to
29ec944
Compare
@Gh1dra Great, thanks! I left a few comments that should be easy to fix. And I also changed the base branch to |
8ff6e63
to
972dba1
Compare
@erak Thanks for the feedback! Let me know if you'd like me to squash the earlier commits. |
Changelog.md
Outdated
@@ -11,7 +11,19 @@ Breaking changes: | |||
* Standard JSON Interface: Add option to disable or choose hash method between IPFS and Swarm for the bytecode metadata. | |||
* Syntax: ``push(element)`` for dynamic storage arrays do not return the new length anymore. | |||
* Type checker: Resulting type of exponentiation is equal to the type of the base. Also allow signed types for the base. | |||
* Natspec JSON Interface: Support multiple ``@return`` statements in dev documentation to behave like named parameters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to be a little bit more specific and mention both, the fixed support and the breaking implication of multiple return statements in the dev docs.
* Natspec JSON Interface: Support multiple ``@return`` statements in dev documentation to behave like named parameters. | |
* Natspec JSON Interface: Support multiple ``@return`` statements in ``@dev`` documentation and force them to have define a name if parameter is named. |
@Gh1dra I've read through it again carefully and found some small issues. I think we can agree on #7534 (comment) quickly and incorporate the outcome. Otherwise your PR looks really good and I'm looking forward to get it merged. |
@Gh1dra Sorry, but it also has merge conflicts. |
088dd8d
to
c88863c
Compare
The branch should be rebased properly now, apologies for the confusion |
@@ -128,7 +128,9 @@ contract LMSRMarketMaker is MarketMaker { | |||
/// @param netOutcomeTokensSold Net outcome tokens sold by market | |||
/// @param funding Initial funding for market | |||
/// @param outcomeIndex Index of exponential term to extract (for use by marginal price function) | |||
/// @return A result structure composed of the sum, the offset used, and the summand associated with the supplied index | |||
/// @return sum of the outcomes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that's probably nit-picking, but these could be changed to /// @return sum The Sum of outcomes
etc.
@@ -60,6 +61,7 @@ class Natspec | |||
/// @return A JSON representation | |||
/// of the contract's developer documentation | |||
static Json::Value devDocumentation(std::multimap<std::string, DocTag> const& _tags); | |||
static Json::Value extractReturnParameterDocs(std::multimap<std::string, DocTag> const& _tags, FunctionDefinition const& _functionDef); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could use some more documentation, perhaps similar to the function devDocumentation
above.
This looks good! I'll rebase and merge. |
…tor test Update 060 doc with natspec change Add two more tests with mixed usage Fix solc-js fix changelog
author:@erak Co-Authored-By: Erik K <[email protected]>
b0eb053
to
f960352
Compare
Description
Addresses #1141
Adds an object similar to the one used to document
params
only if multiple named return parameters are specified. Otherwise thereturn
field will contain a single string.Checklist