Skip to content
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

Merged
merged 6 commits into from
Nov 6, 2019

Conversation

corydickson
Copy link
Contributor

@corydickson corydickson commented Oct 13, 2019

Description

Addresses #1141

Adds an object similar to the one used to document params only if multiple named return parameters are specified. Otherwise the return field will contain a single string.

Checklist

  • Code compiles correctly
  • All tests are passing
  • New tests have been created which fail without the change (if possible)
  • README / documentation was extended, if necessary(?)
  • Changelog entry (if change is visible to the user)
  • Used meaningful commit messages

@corydickson corydickson force-pushed the return-multiple-natspec branch 4 times, most recently from 2a14c7a to a97e996 Compare October 13, 2019 06:46
" \"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"
Copy link
Collaborator

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;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is off.

Copy link
Collaborator

@erak erak left a 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.

@erak
Copy link
Collaborator

erak commented Oct 16, 2019

Please also add a Changelog entry since this is a user-facing change that will effect tools.

@corydickson
Copy link
Contributor Author

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.

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 param adding the return case for parseDocTag. Though this would break most contract documentation i.e. the gnosis contract examples, no?

@erak
Copy link
Collaborator

erak commented Oct 18, 2019

@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.

@erak
Copy link
Collaborator

erak commented Oct 18, 2019

The failing macOS build (b_osx) should be gone after a rebase, which will include #7552.

@corydickson corydickson force-pushed the return-multiple-natspec branch from fcf1990 to 29ec944 Compare October 21, 2019 22:21
@erak erak changed the base branch from develop to develop_060 October 23, 2019 14:30
@erak
Copy link
Collaborator

erak commented Oct 23, 2019

@Gh1dra Great, thanks! I left a few comments that should be easy to fix. And I also changed the base branch to develop_060 since it's breaking. Could you please rebase your changes on top of it as well?
We need an entry in solidity_repo/docs/060-breaking-changes.rst as well. You can run the HTML generation with ./scripts/docs.sh.

@corydickson corydickson force-pushed the return-multiple-natspec branch 2 times, most recently from 8ff6e63 to 972dba1 Compare October 27, 2019 15:23
@corydickson
Copy link
Contributor Author

@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.
Copy link
Collaborator

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.

Suggested change
* 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.

Changelog.md Outdated Show resolved Hide resolved
@erak
Copy link
Collaborator

erak commented Oct 28, 2019

@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.

@erak
Copy link
Collaborator

erak commented Oct 28, 2019

@Gh1dra Sorry, but it also has merge conflicts.

@corydickson corydickson force-pushed the return-multiple-natspec branch 6 times, most recently from 088dd8d to c88863c Compare October 28, 2019 20:51
@corydickson
Copy link
Contributor Author

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
Copy link
Collaborator

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);
Copy link
Collaborator

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.

Changelog.md Outdated Show resolved Hide resolved
@chriseth
Copy link
Contributor

chriseth commented Nov 6, 2019

This looks good! I'll rebase and merge.

@chriseth chriseth force-pushed the return-multiple-natspec branch from b0eb053 to f960352 Compare November 6, 2019 20:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants