Followup to #14373.
Now, only these appear in description text:
0boolean
1numeric
2string
3
4json array
5json array of xs
6json object
7json object of xs
683@@ -684,12 +684,12 @@ static UniValue getbalance(const JSONRPCRequest& request)
684
685 if (request.fHelp || (request.params.size() > 3 ))
686 throw std::runtime_error(
687- "getbalance ( \"(dummy)\" minconf include_watchonly )\n"
688+ "getbalance ( dummy minconf include_watchonly )\n"
dummy
is a string.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, 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.
244@@ -245,6 +245,11 @@ static UniValue uptime(const JSONRPCRequest& jsonRequest)
245 + HelpExampleRpc("uptime", "")
246 );
247
248+ const UniValue& dummy_value = jsonRequest.params[0];
249+ if (!dummy_value.isNull()) {
250+ throw JSONRPCError(RPC_INVALID_PARAMETER, "No dummy first argument may be included.");
251+ }
252+
> 1
with > 0
a few lines up?
prioritisetransaction
has an argument with a space. Mind to replace the space with underscore?
getbalance
has an argument name with a opening bracket. Mind to remove those brackets from the name?
1112@@ -1108,8 +1113,8 @@ UniValue importmulti(const JSONRPCRequest& mainRequest)
1113 "importmulti \"requests\" ( \"options\" )\n\n"
0 "importmulti \"requests\" ( \"options\" )\n"
prioritisetransaction
and getbalance
changes are already in the PR.
Edit: All above issues by MarcoFalke have been resolved by the latest code having transitioned to RPCHelpMan
.
19@@ -20,7 +20,7 @@ UniValue getzmqnotifications(const JSONRPCRequest& request)
20 "\nReturns information about the active ZeroMQ notifications.\n"
21 "\nResult:\n"
22 "[\n"
23- " { (json object)\n"
24+ " { (object)\n"
Damn, they need to make a sed
-builder plugin alongside find-and-replace in vscode, that supports negation. Way easier workflow for newer contributors than all the nuanced escape characters that are necessary in *nix tools.
Is it preferred to use git grep (-l) (-L)
or find . x
in scripted diffs?
Also, does this really make it easier to review for correctness? I’m not so sure. Verification is always good
Next commit will be a scripted diff for:
Replace
(boolean)W
with(boolean) W
in.
git grep -l "(boolean)W" | xargs sed -i "s/(boolean)W/(boolean) W/g"
is about right I think?
What if I’m stuck in PowerShell! No xargs
available.
gsed
is needed to replicate sed
behavior performed in scripted-diffs
sed -i --regexp-extended -e 's/\(json (array|object)/(\1/g' $(git grep -l '(json ')
. There might be a hack to make it work on macOS, but we mostly care that it runs on Ubuntu et al.
Could rebase and squash with something like:
0git fetch bitcoin
1git checkout fix/rpc-descriptions
2git merge bitcoin/master
3git reset --soft bitcoin/master
4git commit -m "More RPC help description fixes"
5git push origin fix/rpc-descriptions --force
master
src/rpc/util.cpp
uses “json object”. Imo everything should use the same
@MarcoFalke I see. To confirm, json array
and json object
everywhere applicable, preferred over array
and object
, aka util.cpp
is set in stone? Will redo as a scripted-diff once more.
Edit: Done. Note: an array
and an object
is still used in bitcoin-core/univalue, and corresponding BTC tests. Additionally, doc/REST-interface.md still uses (object)
and (array)
, since it mentions JSON beforehand.
313@@ -314,12 +314,12 @@ static UniValue getblocktemplate(const JSONRPCRequest& request)
314 {"template_request", RPCArg::Type::OBJ, /* opt */ true, /* default_val */ "", "A json object in the following spec",
315 {
316 {"mode", RPCArg::Type::STR, /* opt */ true, /* default_val */ "", "This must be set to \"template\", \"proposal\" (see BIP 23), or omitted"},
317- {"capabilities", RPCArg::Type::ARR, /* opt */ true, /* default_val */ "", "A list of strings",
318+ {"capabilities", RPCArg::Type::ARR, /* opt */ true, /* default_val */ "", "An array of strings",
A json array
here instead?
-BEGIN VERIFY SCRIPT-
git grep -l "(array of" src | xargs sed -i "s/(array of/(json array of/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "of Objects" src | xargs sed -i "s/of Objects/of json objects/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "(list of objects)" src | xargs sed -i "s/(list of objects)/(json array of json objects)/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "(bool) " src | xargs sed -i "s/(bool) /(boolean) /g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "of objects[)\.]" src/rpc src/wallet | xargs sed -i "s/of objects/of json objects/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l " an object" src/rpc src/wallet | xargs sed -i "s/ an object/ a json object/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "of string)" src/rpc src/wallet | xargs sed -i "s/of string)/of strings)/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "A list of " src/rpc/mining.cpp | xargs sed -i "s/A list of /An array of /g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "Must be one of\\\n" src | xargs sed -i "s/Must be one of\\\n/Must be one of:\\\n/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "[aA]n array" src/rpc src/wallet | xargs sed -i "s/an array/a json array/g"
git grep -l "[aA]n array" src/rpc src/wallet | xargs sed -i "s/An array/A json array/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "pair not an object" test/functional/rpc_rawtransaction.py | xargs sed -i "s/pair not an object/pair not a json object/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "of numeric" src/rpc/blockchain.cpp | xargs sed -i "s/of numeric/of numerics/g"
-END VERIFY SCRIPT-
-BEGIN VERIFY SCRIPT-
git grep -l "(object) " src/wallet src/rpc | xargs sed -i "s/(object) /(json object) /g"
-END VERIFY SCRIPT-
Concept ACK.
Though I think the jargon switch to numeric
loses information.
The code, in practice, makes a difference between numeric
(in general) and integer
. For example where get_int
is used, only an integer will be accepted. Not a decimal value with a point.