This is a follow-up PR to #18197 that fixes RPCExamples.
Fixes #18185.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
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.
utACK: looks like an improvement to the tests + docs
Concept ACK
1088 | @@ -1089,11 +1089,11 @@ A few guidelines for introducing and reviewing new RPC interfaces: 1089 | new RPC is replacing a deprecated RPC, to avoid both RPCs confusingly 1090 | showing up in the command list. 1091 | 1092 | -- Use *invalid* bech32 addresses (e.g. the constant `EXAMPLE_ADDRESS`) for 1093 | +- Use *invalid* addresses (e.g. in the constant array `EXAMPLE_ADDRESS`) for
The "bech32" part is actually important here, as we want to get rid of legacy addresses in the long term. Without that the reader of the guideline may think that any address format is fine.
1093 | +- Use *invalid* addresses (e.g. in the constant array `EXAMPLE_ADDRESS`) for 1094 | `RPCExamples` help documentation. 1095 | 1096 | - *Rationale*: Prevent accidental transactions by users and encourage the use 1097 | - of bech32 addresses by default. 1098 | + of example addresses by default.
That doesn't make sense. "Encourage the use of..." adresses the user of the software here, not the developer. As above, "bech32" should stay here.
43 | @@ -44,8 +44,8 @@ static UniValue validateaddress(const JSONRPCRequest& request) 44 | "}\n" 45 | }, 46 | RPCExamples{ 47 | - HelpExampleCli("validateaddress", EXAMPLE_ADDRESS) + 48 | - HelpExampleRpc("validateaddress", EXAMPLE_ADDRESS) 49 | + HelpExampleCli("validateaddress", EXAMPLE_ADDRESS[1]) +
The quotation marks around the address are missing. Previously they were included in EXAMPLE_ADDRESS, now as the constant contains the bare address, so they have to be added here.
3773 | @@ -3774,8 +3774,8 @@ UniValue getaddressinfo(const JSONRPCRequest& request) 3774 | "}\n" 3775 | }, 3776 | RPCExamples{ 3777 | - HelpExampleCli("getaddressinfo", EXAMPLE_ADDRESS) + 3778 | - HelpExampleRpc("getaddressinfo", EXAMPLE_ADDRESS) 3779 | + HelpExampleCli("getaddressinfo", EXAMPLE_ADDRESS[1]) +
The quotation marks around the address are missing (see comment to "validateaddress" above).
I'm not sure if it's a good idea to mix legacy and bech32 addresses in the same examples address array. The confusing consequence is that the index of the address array determines the resulting address type, and if someone e.g. would add another legacy address in front, many help strings that accessed at index 1 to get bech32 examples address woud then show legacy addresses again. To prevent that, it would be even okay right now if the legacy addresses stay in hardcoded (and the guidelines remain untouched).
LGTM now, can you squash the commits, please? In the course of that, you could also change the commit title to be more descriptive (e.g. "change to bech32" than just "fix").
28 | @@ -29,10 +29,10 @@ 29 | extern const std::string UNIX_EPOCH_TIME; 30 | 31 | /** 32 | - * Example bech32 address used in multiple RPCExamples. The address is intentionally 33 | + * Example bech32 addresses for multiple use in RPCExamples. The address is intentionally
s/address is/addresses are/, remove "multiple" (it's understood with RPCExamples being plural), suggestion:
- * Example bech32 address used in multiple RPCExamples. The address is intentionally
+ * Example bech32 addresses for the RPCExamples help documentation. They are intentionally
Concept ACK
ACK 3e32499909ca8127baaa9b40ad113b25ee151bbd
ACK 3e32499