Skip to content

Conversation

maflcko
Copy link
Member

@maflcko maflcko commented Jun 11, 2020

Currently calling help on a wallet RPC method will either return help: unknown command: getnewaddress or the actual help. This runtime dependency of the help is a bug that complicates any tool that relies on documentation. Also, the code that enables the bug is overly complicated and confusing.

The fix is split into two commits:

  • First, a commit that can be reviewed with the --color-moved=dimmed-zebra option and tested with the included test.
  • Second, a commit that removes the complicated and confusing code.

@maflcko
Copy link
Member Author

maflcko commented Jun 11, 2020

This bugfix has been split out from #18531

@achow101
Copy link
Member

ACK fae7923

@laanwj
Copy link
Member

laanwj commented Jun 11, 2020

I don't think calling this 'move-only', while strictly correct, is what we usually mean with that. It implies that whole functions are moved keeping the functionality the same hence 'move-only'.

ACK otherwise. The help doesn't depend on the wallet being loaded, or what wallet is selected, so moving this upfront makes sense.

@maflcko maflcko changed the title wallet: [move-only bugfix] Make RPC help compile-time static wallet: Make RPC help compile-time static Jun 11, 2020
@maflcko maflcko force-pushed the 2006-rpcWalletHelp branch from fae7923 to fadf6bd Compare June 11, 2020 16:39
@maflcko
Copy link
Member Author

maflcko commented Jun 11, 2020

Force pushed to removed "move-only bugfix" from the pull request title and commit subject line. No other changes:

$ git range-diff  bitcoin-core/master  fae7923a0b fadf6bd04f
1:  fafcc0d8f5 ! 1:  fad889cbf0 wallet move-only bugfix: Make RPC help compile-time static
    @@ Metadata
     Author: MarcoFalke <falke.marco@gmail.com>
     
      ## Commit message ##
    -    wallet move-only bugfix: Make RPC help compile-time static
    +    wallet: Make RPC help compile-time static
     
      ## src/wallet/rpcdump.cpp ##
     @@ src/wallet/rpcdump.cpp: static void RescanWallet(CWallet& wallet, const WalletRescanReserver& reserver,
2:  fae7923a0b = 2:  fadf6bd04f refactor: Remove unused request.fHelp

Copy link
Contributor

@promag promag left a comment

Choose a reason for hiding this comment

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

Tested ACK fadf6bd.

I've pushed f11f864 that I think you could cherry pick here.

Only change is that now you can call help on invalid wallets, like src/bitcoin-cli -rpcwallet=404 -regtest help listunspent and it doesn't error.

return wallets[0];
}

if (request.fHelp) return nullptr;

if (!HasWallets()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

if (if wallets.size() == 0) and ditch HasWallets.

Copy link
Member Author

Choose a reason for hiding this comment

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

This has one ACK and two stale ACKs, so I'd prefer to keep it as is for now. Maybe @ryanofsky can combine this into the other vpwallets cleaunup?

Copy link
Contributor

Choose a reason for hiding this comment

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

I can open a PR but it's too damn height. No rush really.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am happy to review if you open a pull request

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok #19261

@achow101
Copy link
Member

re-ACK fadf6bd

@maflcko maflcko merged commit 19e9192 into bitcoin:master Jun 12, 2020
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 12, 2020
fadf6bd refactor: Remove unused request.fHelp (MarcoFalke)
fad889c wallet: Make RPC help compile-time static (MarcoFalke)

Pull request description:

  Currently calling `help` on a wallet RPC method will either return `help: unknown command: getnewaddress` or the actual help. This runtime dependency of the help is a bug that complicates any tool that relies on documentation. Also, the code that enables the bug is overly complicated and confusing.

  The fix is split into two commits:

  * First, a commit that can be reviewed with the `--color-moved=dimmed-zebra` option and tested with the included test.
  * Second, a commit that removes the complicated and confusing code.

ACKs for top commit:
  achow101:
    re-ACK fadf6bd
  promag:
    Tested ACK fadf6bd.

Tree-SHA512: 65d4ff400467f57cb8415c30ce30f814dc76c5c157308b7a7409c59ac9db629e65dfba31cd9c389cfe60a008d3d87787ea0a0e0f2671fd65fd190543c915493d
@maflcko maflcko deleted the 2006-rpcWalletHelp branch June 12, 2020 20:47
maflcko pushed a commit that referenced this pull request Jun 13, 2020
ccf1f6e refactor: Drop ::HasWallets() (João Barbosa)

Pull request description:

  Minor follow-up of #19250. The global `HasWallets()` is used only once and at the call site there's already a way to know if any wallet is loaded.

ACKs for top commit:
  MarcoFalke:
    ACK ccf1f6e
  hebasto:
    ACK ccf1f6e, I have reviewed the changes and they look OK, I agree they can be merged.

Tree-SHA512: fb902c045cbd331eaf71716c04734520f2ce7f2b317db510c4ce140162bbc683327b5a40ac860f6cde5add37e069065274d39dfa147fac2091eedec505f2f7eb
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 14, 2020
ccf1f6e refactor: Drop ::HasWallets() (João Barbosa)

Pull request description:

  Minor follow-up of bitcoin#19250. The global `HasWallets()` is used only once and at the call site there's already a way to know if any wallet is loaded.

ACKs for top commit:
  MarcoFalke:
    ACK ccf1f6e
  hebasto:
    ACK ccf1f6e, I have reviewed the changes and they look OK, I agree they can be merged.

Tree-SHA512: fb902c045cbd331eaf71716c04734520f2ce7f2b317db510c4ce140162bbc683327b5a40ac860f6cde5add37e069065274d39dfa147fac2091eedec505f2f7eb
maflcko pushed a commit that referenced this pull request Jul 15, 2020
…ones (server)

fa7592b rpc: Update server to use new RPCHelpMan (MarcoFalke)
aaaaad5 rpc: Add option to hide RPCArg (MarcoFalke)
fa9708f rpc: Assert that passed arg names are equal to hardcoded ones (MarcoFalke)
faaeb2b rpc: Add CRPCCommand constructor which takes RPCHelpMan (MarcoFalke)
fa8ec00 rpc: Check that left section is not multiline (MarcoFalke)

Pull request description:

  This is split out from #18531 to just touch the RPC methods in server. 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 #18607
  * The changes itself fixed bug #19250

ACKs for top commit:
  laanwj:
    ACK fa7592b
  ryanofsky:
    Code review ACK fa7592b. Looks great! Just some hidden arg and Check() and comment cleanups since last review

Tree-SHA512: e64b6a212f4a3aeedeee47557559bde104d5fd40cdc1746b27eb2f3d4c8885d5e6e4dd287595ea11cdbc6a939654fe103cae765fd505875444d851f0abb11308
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jul 16, 2020
…ommand ones (server)

fa7592b rpc: Update server to use new RPCHelpMan (MarcoFalke)
aaaaad5 rpc: Add option to hide RPCArg (MarcoFalke)
fa9708f rpc: Assert that passed arg names are equal to hardcoded ones (MarcoFalke)
faaeb2b rpc: Add CRPCCommand constructor which takes RPCHelpMan (MarcoFalke)
fa8ec00 rpc: Check that left section is not multiline (MarcoFalke)

Pull request description:

  This is split out from bitcoin#18531 to just touch the RPC methods in server. 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:
    ACK fa7592b
  ryanofsky:
    Code review ACK fa7592b. Looks great! Just some hidden arg and Check() and comment cleanups since last review

Tree-SHA512: e64b6a212f4a3aeedeee47557559bde104d5fd40cdc1746b27eb2f3d4c8885d5e6e4dd287595ea11cdbc6a939654fe103cae765fd505875444d851f0abb11308
maflcko pushed a commit that referenced this pull request Aug 14, 2020
…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 #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 #18607
  * The changes itself fixed bug #19250

ACKs for top commit:
  laanwj:
    Code review ACK fa77de2
  fjahr:
    tested ACK fa77de2
  theStack:
    ACK fa77de2
  ryanofsky:
    Code review ACK fa77de2. Pretty straightfoward changes

Tree-SHA512: badae1606518c0b55ce2c0bb9025d14f05556532375eb20fd6f3bfadae1e5e6568860bff8599d037e655bf1d23f1f464ca17f4db10a6ab3d502b6e9e61c7b3d3
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 16, 2020
…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
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 16, 2020
…ommand ones (server)

fa7592b rpc: Update server to use new RPCHelpMan (MarcoFalke)
aaaaad5 rpc: Add option to hide RPCArg (MarcoFalke)
fa9708f rpc: Assert that passed arg names are equal to hardcoded ones (MarcoFalke)
faaeb2b rpc: Add CRPCCommand constructor which takes RPCHelpMan (MarcoFalke)
fa8ec00 rpc: Check that left section is not multiline (MarcoFalke)

Pull request description:

  This is split out from bitcoin#18531 to just touch the RPC methods in server. 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:
    ACK fa7592b
  ryanofsky:
    Code review ACK fa7592b. Looks great! Just some hidden arg and Check() and comment cleanups since last review

Tree-SHA512: e64b6a212f4a3aeedeee47557559bde104d5fd40cdc1746b27eb2f3d4c8885d5e6e4dd287595ea11cdbc6a939654fe103cae765fd505875444d851f0abb11308
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Aug 31, 2020
…ommand ones (mining,zmq,rpcdump)

fa3d9ce rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46d rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc1 rpc: Remove unused return type from appendCommand (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:
  fjahr:
    tested ACK fa3d9ce
  promag:
    Code review ACK fa3d9ce.

Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 31, 2020
…ommand ones (mining,zmq,rpcdump)

fa3d9ce rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46d rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc1 rpc: Remove unused return type from appendCommand (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:
  fjahr:
    tested ACK fa3d9ce
  promag:
    Code review ACK fa3d9ce.

Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
maflcko pushed a commit that referenced this pull request Sep 22, 2020
…(blockchain,rawtransaction)

fa6bb0c Assert that RPCArg names are equal to CRPCCommand ones (rawtransaction) (MarcoFalke)
fa80c81 Assert that RPCArg names are equal to CRPCCommand ones (blockchain) (MarcoFalke)

Pull request description:

  This is split out from #18531 to just touch some RPC methods. 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 #18607
  * The changes itself fixed bug #19250

ACKs for top commit:
  fjahr:
    utACK fa6bb0c
  tryphe:
    utACK fa6bb0c. Reducing data duplication is nice. Code changes are minimal and concise.

Tree-SHA512: deb0edc3f999baf055526eaa199b98c500635e12502dece7aa3cad5319db330eb5ee7459a5c8f040a83671a7f20c560c19a2026fb76c8416f138aa332727cbce
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 23, 2020
…d ones (blockchain,rawtransaction)

fa6bb0c Assert that RPCArg names are equal to CRPCCommand ones (rawtransaction) (MarcoFalke)
fa80c81 Assert that RPCArg names are equal to CRPCCommand ones (blockchain) (MarcoFalke)

Pull request description:

  This is split out from bitcoin#18531 to just touch some RPC methods. 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:
  fjahr:
    utACK fa6bb0c
  tryphe:
    utACK fa6bb0c. Reducing data duplication is nice. Code changes are minimal and concise.

Tree-SHA512: deb0edc3f999baf055526eaa199b98c500635e12502dece7aa3cad5319db330eb5ee7459a5c8f040a83671a7f20c560c19a2026fb76c8416f138aa332727cbce
maflcko pushed a commit that referenced this pull request Sep 23, 2020
…(net, rpcwallet)

fa14f57 Assert that RPCArg names are equal to CRPCCommand ones (net, rpcwallet) (MarcoFalke)

Pull request description:

  This is the last part split out from #18531 to just touch some RPC methods. 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 #18607
  * The changes itself fixed bug #19250

ACKs for top commit:
  fjahr:
    tACK fa14f57
  ryanofsky:
    Code review ACK fa14f57. Just straightforward replacements except code moved in `addnode`, and displatching updated in `bumpfee_helper`

Tree-SHA512: e07af150f1d95a88e558256ce197a6b7dc6cd722a6d6c13c75d944c49c2e2441f8b8237e9f94b03db69fa18f9bda627b0781d5e1da70bf5415e09b38728a8cb1
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 23, 2020
…d ones (net, rpcwallet)

fa14f57 Assert that RPCArg names are equal to CRPCCommand ones (net, rpcwallet) (MarcoFalke)

Pull request description:

  This is the last part split out from bitcoin#18531 to just touch some RPC methods. 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:
  fjahr:
    tACK fa14f57
  ryanofsky:
    Code review ACK fa14f57. Just straightforward replacements except code moved in `addnode`, and displatching updated in `bumpfee_helper`

Tree-SHA512: e07af150f1d95a88e558256ce197a6b7dc6cd722a6d6c13c75d944c49c2e2441f8b8237e9f94b03db69fa18f9bda627b0781d5e1da70bf5415e09b38728a8cb1
maflcko pushed a commit that referenced this pull request Nov 19, 2020
faaf9c5 remove CRPCCommand constructor that takes rpcfn_type function pointer (MarcoFalke)
fa19bb2 remove dead rpc code (MarcoFalke)

Pull request description:

  Remove the CRPCCommand arguments, now that they are asserted to be equal and thus redundant

  ### 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 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 #18607
  * The changes itself fixed bug #19250

ACKs for top commit:
  fjahr:
    tested ACK faaf9c5
  promag:
    Tested ACK faaf9c5.
  ryanofsky:
    Code review ACK faaf9c5. Two obviously good simplifications.

Tree-SHA512: 5de3b440f7b2ed2c3e86655d4f0e2e5df9c67e8ce3c7817d5ea5311d1a38690f2f3e28fab41aad6936be9fc884326d037e5f19e85d4d2fe281474dada13911ee
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Nov 19, 2020
faaf9c5 remove CRPCCommand constructor that takes rpcfn_type function pointer (MarcoFalke)
fa19bb2 remove dead rpc code (MarcoFalke)

Pull request description:

  Remove the CRPCCommand arguments, now that they are asserted to be equal and thus redundant

  ### 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 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:
  fjahr:
    tested ACK faaf9c5
  promag:
    Tested ACK faaf9c5.
  ryanofsky:
    Code review ACK faaf9c5. Two obviously good simplifications.

Tree-SHA512: 5de3b440f7b2ed2c3e86655d4f0e2e5df9c67e8ce3c7817d5ea5311d1a38690f2f3e28fab41aad6936be9fc884326d037e5f19e85d4d2fe281474dada13911ee
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Apr 29, 2021
Summary:
> Currently calling help on a wallet RPC method will either return help: unknown command: getnewaddress or the actual help. This runtime dependency of the help is a bug that complicates any tool that relies on documentation. Also, the code that enables the bug is overly complicated and confusing.
>
> The fix is split into two commits:
>
>  - First, a commit that can be reviewed with the --color-moved=dimmed-zebra option and tested with the included test.
>  - Second, a commit that removes the complicated and confusing code.

This is a backport of [[bitcoin/bitcoin#19250 | core#19250]] [1/2]
bitcoin/bitcoin@fad889c

Depends on D9452

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D9455
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Apr 29, 2021
Summary:
This concludes backport of [[bitcoin/bitcoin#19250 | core#19250]] [2/2]
bitcoin/bitcoin@fadf6bd

Depends on D9455

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D9456
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Apr 29, 2021
Summary:
> Minor follow-up of [[bitcoin/bitcoin#19250 | core#19250]]. The global HasWallets() is used only once and at the call site there's already a way to know if any wallet is loaded.

This is a backport of [[bitcoin/bitcoin#19261 | core#19261]]

Depends on D9456

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D9457
cryptapus pushed a commit to cryptapus/bitcoin that referenced this pull request May 3, 2021
cryptapus pushed a commit to cryptapus/bitcoin that referenced this pull request May 3, 2021
Updated RPCs for Bitcoin PRs bitcoin#19100 and bitcoin#19250.
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants