-
Notifications
You must be signed in to change notification settings - Fork 36.5k
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
rpc: Assert that RPCArg names are equal to CRPCCommand ones (misc) #19528
Conversation
faffa2d
to
fa131b0
Compare
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
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.
Concept ACK. As far as I see, this mainly uses the new CRPCCommand constructor that was introduced in an earlier PR. Will review the main commit more in detail.
fa131b0
to
fa7e8b0
Compare
Thanks, fixed leftover |
fa7e8b0
to
fae864b
Compare
This commit has no effect right now, but hardens the code for the future
fae864b
to
fa77de2
Compare
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.
ACK fa77de2
For a small code readability nit, I think it makes sense to re-indent after all RPC modules have been updated to use the new RPCHelpMan. The first few ctor arguments to RPCHelpMan seem to be over-indented, while the function body seems under-indented, which looks quite odd. Would personally prefer it like this:
static RPCHelpMan somecoolrpcmethod()
{
return RPCHelpMan{"name",
"\ndescription\n",
{
...
},
RPCResult{
...
},
RPCExamples{
...
},
[&](const RPCHelpMan& self, const JSONRPCRequest& request) -> UniValue
{
...
},
};
}
|
||
CHECK_NONFATAL(request.params.size() != 100); | ||
if (request.params[9].isStr()) { |
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 don't think multiplexing an argument on string/number type is generally a good idea. Because it's harder to use from some (statically typed) languages, and even from bitcoin-cli
I think.. But for a test call ti's fine so no problem here specifically, but it's not something to encourage.
Code review ACK fa77de2 |
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.
Code review ACK fa77de2. Pretty straightfoward changes
…ommand ones (misc) fa77de2 rpc: Assert that RPCArg names are equal to CRPCCommand ones (misc) (MarcoFalke) fa50bdc rpc: Limit echo to 10 args (MarcoFalke) fa89ca9 refactor: Use C++11 range based for loops to simplify rpc code (MarcoFalke) fa459bd rpc: Treat all args after a hidden arg as hidden as well (MarcoFalke) Pull request description: This is split out from bitcoin#18531 to just touch the RPC methods in misc. Description from the main pr: ### Motivation RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here. ### Changes The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`. ### Future work > Here or follow up, makes sense to also assert type of returned UniValue? Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including: * Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant * Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table * Auto-formatting and sanity checking the RPCExamples with RPCMan * Checking passed-in json in self-check. Removing redundant checks * Checking returned json against documentation to avoid regressions or false documentation * Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static ### Bugs found * The assert identified issue bitcoin#18607 * The changes itself fixed bug bitcoin#19250 ACKs for top commit: laanwj: Code review ACK fa77de2 fjahr: tested ACK fa77de2 theStack: ACK bitcoin@fa77de2 ryanofsky: Code review ACK fa77de2. Pretty straightfoward changes Tree-SHA512: badae1606518c0b55ce2c0bb9025d14f05556532375eb20fd6f3bfadae1e5e6568860bff8599d037e655bf1d23f1f464ca17f4db10a6ab3d502b6e9e61c7b3d3
Summary: This commit has no effect right now, but hardens the code for the future PR description: > Motivation > > RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the CRPCCommands and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here. > > Changes > > The changes here add an assert in the CRPCCommand constructor that the RPCArg names are identical to the ones in the CRPCCommand. This is a backport of [[bitcoin/bitcoin#19528 | core#19528]] [1/4] bitcoin/bitcoin@fa459bd Depends on D10010 Test Plan: `ninja all check-all` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D10080
Summary: This is a backport of [[bitcoin/bitcoin#19528 | core#19528]] [2/4] bitcoin/bitcoin@fa89ca9 Depends on D10080 Test Plan: `ninja all check-all` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D10081
Summary: This is a backport of [[bitcoin/bitcoin#19528 | core#19528]] [3/4] bitcoin/bitcoin@fa50bdc Note: one line of documentation for the `echo` RPC seems to have been accidentaly deleted in D5920. This restores it before applying the change. Depends on D10081 Test Plan: `ninja && ninja check-functional` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D10082
Summary: This is a backport of [[bitcoin/bitcoin#19528 | core#19528]] [4/4] bitcoin/bitcoin@fa77de2 Depends on D10082 Test Plan: `ninja all check-all` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D10083
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the
CRPCCommand
s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.Changes
The changes here add an assert in the
CRPCCommand
constructor that the RPCArg names are identical to the ones in theCRPCCommand
.Future work
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
Bugs found