and rename BCLog::BLOCKSTORE to BLOCKSTORAGE so the enum is the same as its value like the other BCLog enums.
Per discussion in bitcoin-core-dev IRC today from https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-11#921458.
and rename BCLog::BLOCKSTORE to BLOCKSTORAGE so the enum is the same as its value like the other BCLog enums.
Per discussion in bitcoin-core-dev IRC today from https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-05-11#921458.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--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.
Concept ACK; trying to -debug= a nonexistent category bit me earlier today.
18 | void AddLoggingArgs(ArgsManager& args); 19 | void SetLoggingOptions(const ArgsManager& args); 20 | -void SetLoggingCategories(const ArgsManager& args); 21 | -void SetLoggingLevel(const ArgsManager& args); 22 | +std::optional<bilingual_str> SetLoggingCategories(const ArgsManager& args); 23 | +std::optional<bilingual_str> SetLoggingLevel(const ArgsManager& args);
nit: document those as the return value may not be so obvious to everybody: "if a non-empty optional is returned then an error occurred and it contains the error message".
nit: document those as the return value may not be so obvious to everybody: "if a non-empty optional is returned then an error occurred and it contains the error message".
It's good to document, but this convention does seem to be increasingly used. I have a PR to replace std::optional<bilingual_str> with util::Result various places (74655e5870888e0165c62fec75000fe04f062147, #25977)
Using util::Result here would be self-documenting.
Thanks @vasild and @ryanofsky. Updated to use util::Result instead.
ACK b9935a4ad512cc0d310d1bd363f71f430b787dbb
ACK 9c74c94714465ac66d82a7e233312d188c9b2841
79 | + self.log.info("Test -loglevel raises when invalid values are passed") 80 | + exp_stderr = r"Error: Unsupported global logging level -loglevel=abc. Valid values: info, debug, trace." 81 | + self.nodes[0].assert_start_raises_init_error(["-loglevel=abc"], exp_stderr, match=ErrorMatch.FULL_REGEX) 82 | + exp_stderr = r"Error: Unsupported category-specific logging level -loglevel=net:abc." 83 | + self.nodes[0].assert_start_raises_init_error(["-loglevel=net:abc"], exp_stderr, match=ErrorMatch.PARTIAL_REGEX) 84 | + exp_stderr = r"Error: Unsupported category-specific logging level -loglevel=net:info:abc."
nit: Any reason to use r-strings when there is no need to and they don't contain any \ chars?
Fixed, thank you.
88 | @@ -88,7 +89,7 @@ void SetLoggingCategories(const ArgsManager& args) 89 | [](std::string cat){return cat == "0" || cat == "none";})) { 90 | for (const auto& cat : categories) { 91 | if (!LogInstance().EnableCategory(cat)) { 92 | - InitWarning(strprintf(_("Unsupported logging category %s=%s."), "-debug", cat)); 93 | + return util::Error{Untranslated(strprintf("Unsupported logging category -debug=%s", cat))};
q: Can you explain why it is fine to drop the translation?
Kept the translation -- thank you.
97 | @@ -97,9 +98,10 @@ void SetLoggingCategories(const ArgsManager& args) 98 | // Now remove the logging categories which were explicitly excluded 99 | for (const std::string& cat : args.GetArgs("-debugexclude")) { 100 | if (!LogInstance().DisableCategory(cat)) { 101 | - InitWarning(strprintf(_("Unsupported logging category %s=%s."), "-debugexclude", cat)); 102 | + return util::Error{Untranslated(strprintf("Unsupported logging category -debugexclude=%s", cat))}; 103 | } 104 | } 105 | + return true;
Not sure if we want to use Result before it supports <void>, but I guess it will be less code to change in the future, compared to std::optional<bilingual_str>, so I guess it is fine for now.
unrelated: A minimal (but hacky) way to add support for void to Result would be:
diff --git a/src/util/result.h b/src/util/result.h
index 972b1aada0..b99995c7e5 100644
--- a/src/util/result.h
+++ b/src/util/result.h
@@ -31,16 +31,19 @@ struct Error {
//! `std::optional<T>` can be updated to return `util::Result<T>` and return
//! error strings usually just replacing `return std::nullopt;` with `return
//! util::Error{error_string};`.
-template <class T>
+template <class M>
class Result
{
private:
+ using T = std::conditional_t<std::is_same_v<M, void>, std::monostate, M>;
+
std::variant<bilingual_str, T> m_variant;
template <typename FT>
friend bilingual_str ErrorString(const Result<FT>& result);
public:
+ Result() : m_variant{std::in_place_index_t<1>{}, std::monostate{}} {} // constructor for void
Result(T obj) : m_variant{std::in_place_index_t<1>{}, std::move(obj)} {}
Result(Error error) : m_variant{std::in_place_index_t<0>{}, std::move(error.message)} {}
Rebased to current master containing 5f49cb1 (#25977) to be able to use Result with support for <void>, and updated the return types from bool to void.
Thank you for the review feedback, @MarcoFalke; addressed, and rebased to current master containing 5f49cb1 (#25977) to use Result with support for <void>. Invalidates previous ACK by @vasild (thanks!)
ACK 1a27bec1e9e40166d6ff7f0492115107289e7609
199 | @@ -200,7 +200,9 @@ BOOST_FIXTURE_TEST_CASE(logging_Conf, LogSetup) 200 | const char* argv_test[] = {"bitcoind", "-loglevel=debug"}; 201 | std::string err; 202 | BOOST_REQUIRE(args.ParseParameters(2, argv_test, err)); 203 | - init::SetLoggingLevel(args); 204 | + 205 | + auto result = init::SetLoggingLevel(args); 206 | + BOOST_REQUIRE(result);
If you're touching unit tests anyway, why not add a test for invalid args here as well?
The unit tests were touched for the nodiscard attribute. End-to-end functional tests seem to be the usual way we test for raising on an invalid config. I didn't look if they can be replaced by faster unit tests. Might be a follow-up if you're interested?
ACK 1a27bec1e9e40166d6ff7f0492115107289e7609
Reviewed code and ran tests locally. Confirmed expected behavior locally with regtest:
--> bcd -regtest -debug=poop
Error: Unsupported logging category -debug=poop
--> bcd -regtest -loglevel=poop
Error: Unsupported global logging level -loglevel=poop. Valid values: info, debug, trace.
Just had a question about workflow/testing below, not a deal breaker.
<details><summary>Show Signature</summary>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ACK 1a27bec1e9e40166d6ff7f0492115107289e7609
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmR6GCQACgkQ5+KYS2KJ
yTr3SQ//W1BkYnevdAkPaNkqd4/k3ELtP5bPb8FY7Xx3HSMBAvE3u5vntGJXD3he
RV82mitdMgoa7qMDT4OktsRGcHRmukPWSJAZWiON2rFkreoZhx7JoDnfokw2Lz01
xDWuO32filsW72EKtJNpc3i5X8GjHrGL1kUIlKL/bfrRPo2iJISB07h3Tg9b2g2K
dKQABPKjoAOWgDUIl2M7LEzyyIwfx5jHfmvGZ1GoKTbLVJ3NHZ+0OjxJJrI3jfjM
voqeKs1NDrcnVM+0ahIqBu42RTF8r48gWGnDCnTV/BnmMCsr3zNhmjmHO7hP39No
hbiJLMn5jsTvrpkoAQzSrexysbO8JwqXjGrh2x9J7A6EPGLIQ7eiB31nthMjUI8x
Fxh5+7YcWoJtb8SH/6NUKvL8688Y2uQrIA2x4uSfS1RvtoshUjfxqXi3C8VSnfHM
dd2K5YosxXYWHukK7ohh/Dr0//g8BLw3C1pesso77kRLpNgyf1u/iqONeuV4CI1O
U6Q1US6OMxBQZ8xNhkGARGCB3UU0l9InxsUAjlkx/LbBPTeMGqyVZcr68dzArYTH
UVQQYhYuxFQffVB/45H4wBtVtQIERa+jiWOQz1OSiiLCA9qQ1cBxv6D/VXpOj9+w
MiLxr+T7oOjqRyjQSXQzwKHRudavjdLC7C3eyJe5HIYxyeQcTgs=
=OynM
-----END PGP SIGNATURE-----
pinheadmz's public key is on keybase
</details>
88 | @@ -88,7 +89,7 @@ void SetLoggingCategories(const ArgsManager& args) 89 | [](std::string cat){return cat == "0" || cat == "none";})) { 90 | for (const auto& cat : categories) { 91 | if (!LogInstance().EnableCategory(cat)) { 92 | - InitWarning(strprintf(_("Unsupported logging category %s=%s."), "-debug", cat)); 93 | + return util::Error{strprintf(_("Unsupported logging category -debug=%s"), cat)};
In commit "init: raise on invalid debug/debugexclude config options" (398aa75f94114684dfee5ea5a2bc9ebe0860bb77)
This commit is adding command line argument names to a translated string, which is something we want to avoid to avoid translation errors. See #20404. Would be better to leave the previous strprintf in place.
Could also remove argument names from translated strings in later commit "init: raise on invalid loglevel config option" (24a9d701390c7fc0d20be44b68d752c051505df9)
Thanks @ryanofsky, I'll update per your feedback.
Code review ACK 1a27bec1e9e40166d6ff7f0492115107289e7609. I left a review comment about this adding some argument names to translated strings, which is bad but already happens other places, so it might not be very important to fix.
I do think it would be good if this PR added release notes, because the changes are not backwards compatible and will probably break some existing configurations or misconfigurations.
It also looks like this has had enough code review to be ready to merge. @jonatack you could respond and say if you'd prefer to merge this as-is or make more updates.
Updated with @ryanofsky's review feedback (thanks!) -- the CI failures look unrelated and perhaps require rebasing to current master (edit: done).
98 | @@ -97,9 +99,10 @@ void SetLoggingCategories(const ArgsManager& args) 99 | // Now remove the logging categories which were explicitly excluded 100 | for (const std::string& cat : args.GetArgs("-debugexclude")) { 101 | if (!LogInstance().DisableCategory(cat)) { 102 | - InitWarning(strprintf(_("Unsupported logging category %s=%s."), "-debugexclude", cat)); 103 | + return util::Error{strprintf(_("Unsupported logging category %s=%s"), "-debugexclude", cat)};
Any reason to remove the trailing dot? This will invalidate the translations and is inconsistent with the other Error messages in this pull?
Fixed, thanks.
Updated with translation string simplifications and improvements and a release note per @ryanofsky and @MarcoFalke feedback and rebased for the CI. Diff since the previous ACKs: git range-diff 681ecac 1a27bec 8bbfeec
72 | } else {
73 | // user passed a category-specific log level, i.e. -loglevel=<category>:<level>
74 | const auto& toks = SplitString(level_str, ':');
75 | if (!(toks.size() == 2 && LogInstance().SetCategoryLogLevel(toks[0], toks[1]))) {
76 | - return util::Error{strprintf(_("Unsupported category-specific logging level -loglevel=%s. Expected -loglevel=<category>:<loglevel>. Valid categories: %s. Valid loglevels: %s."), level_str, LogInstance().LogCategoriesString(), LogInstance().LogLevelsString())};
77 | + return util::Error{strprintf(_("Unsupported category-specific logging level %s=%s. Expected %s=<category>:<loglevel>. Valid categories: %s. Valid loglevels: %s."), "-loglevel", level_str, "-loglevel", LogInstance().LogCategoriesString(), LogInstance().LogLevelsString())};
In commit "init: remove config option names from translated -loglevel strings" (1798c21f8c2557dbcfbcb8d33d6d70b0ea539a98)
Could use %1$s, %2$s format strings to remove the redundant "-loglevel" translation argument and remove ambiguity about which of the two arguments a translator is supposed to use.
Good idea, done (thanks!)
Code review ACK 8bbfeecdda5648b497fc0442c8929563ee70f301. Looks great! Changes since last review are keeping option names out of translated strings, and adding a release note
so the enum name is the same as its value, like the other BCLog enums.
Updated to incorporate @ryanofsky's #27632 (review) to use format strings in https://github.com/bitcoin/bitcoin/pull/27632/commits/6cb1c66041ee14dbedad3aeeb90190ea5dddf917 to drop a redundant translation argument and remove ambiguity about which of the two arguments a translator is supposed to use (thanks!)
Code review ACK daa5a658c0e79172e4dea0758246f11281790d29. Just translated string template cleanup since last review
re-ACK daa5a658c0e79172e4dea0758246f11281790d29
Confirmed trivial change since last review with
git range-diff 681ecac5c2 daa5a658c0 1a27bec1e9
rebuilt and reran tests as well
<details><summary>Show Signature</summary>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ACK daa5a658c0e79172e4dea0758246f11281790d29
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmSR2uUACgkQ5+KYS2KJ
yTqrdhAAve71Ldk9R/7TcK8NDh8p797syW3+rJfSNV6nb3TYcjMl57iOiYIEVHer
kIqDadhGOMPmw0mKHUqoaAkNgI5E6hJLWx4FWBTbtlUmGAKCwqfD30AmFMqjF4GL
6F+GuexZYMTxc2v0Y0KoXUagXwPGwUaP/NTMgsBkhpBLEQKTdGc8kVpxPLPwEDTa
hxdYl5GgHcYcMT4XkT26RzQMFswIhlmM4XszygIUVmg6JExcllRbaUjVMAAtTouk
lEeFjtTYitWyNwvbeUYr02mh75IncHf6x50CJdVNfHEVEEEfV4utzPhx6wUs94Ru
d+E4s92V0Ku0trn0tWb276I3LXhIeJ/8ESFXnkLF3DMfT0GLJnx78cxcDa49DBt0
+wCUtyssZ519sBnt+gt7MFYZqIomzkZjUTQ2+G9RJTMv9AW+gcYxHFit40Zb7vkm
DSN0M9v3UB4STeiZsH+gdkgvnmjDZHKROfds8dsEbCzgYs7MHzkmiFerDVXZTlcM
P4T+MQ9O15S4o6gc+65187xc30vtr7DSpsxS1pi5VXDwox9sk6paTB9FU1qxN9hA
ZvLTDqUvjYHd5stC9GzcA+jJF9WjjWslRCaoVVptX2GBO0i2a9DajsvtUUqurFAl
RQYhec4+Q7NiZKJP7jgimNXhlhR7XMHRT1tmJN9jD9m90kFM1Mg=
=EsDp
-----END PGP SIGNATURE-----
pinheadmz's public key is on keybase
</details>
ACK daa5a658c0e79172e4dea0758246f11281790d29