-
Notifications
You must be signed in to change notification settings - Fork 36.6k
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
tinyformat: refactor: increase compile-time checks and don"t throw for tfm::format_error #30928
Changes from 1 commit
104c805
4ce60d8
4cf1221
49f7307
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
All (non-test) format strings are known at compile-time, so we don"t need the std::string overload. Remove it so users use the safer util::ConstevalFormatString where possible, or the bilingual_str overload where applicable.
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1891,7 +1891,7 @@ CWallet::ScanResult CWallet::ScanForWalletTransactions(const uint256& start_bloc | |
fast_rescan_filter ? "fast variant using block filters" : "slow variant inspecting all blocks"); | ||
|
||
fAbortRescan = false; | ||
ShowProgress(strprintf("%s " + _("Rescanning…").translated, GetDisplayName()), 0); // show rescan progress in GUI as dialog or on splashscreen, if rescan required on startup (e.g. due to corruption) | ||
ShowProgress(strprintf("%s %s", GetDisplayName(), _("Rescanning…").translated), 0); // show rescan progress in GUI as dialog or on splashscreen, if rescan required on startup (e.g. due to corruption) | ||
uint256 tip_hash = WITH_LOCK(cs_wallet, return GetLastBlockHash()); | ||
uint256 end_hash = tip_hash; | ||
if (max_height) chain().findAncestorByHeight(tip_hash, *max_height, FoundBlock().hash(end_hash)); | ||
|
@@ -1906,7 +1906,7 @@ CWallet::ScanResult CWallet::ScanForWalletTransactions(const uint256& start_bloc | |
m_scanning_progress = 0; | ||
} | ||
if (block_height % 100 == 0 && progress_end - progress_begin > 0.0) { | ||
ShowProgress(strprintf("%s " + _("Rescanning…").translated, GetDisplayName()), std::max(1, std::min(99, (int)(m_scanning_progress * 100)))); | ||
ShowProgress(strprintf("%s %s", GetDisplayName(), _("Rescanning…").translated), std::max(1, std::min(99, (int)(m_scanning_progress * 100)))); | ||
} | ||
|
||
bool next_interval = reserver.now() >= current_time + INTERVAL_TIME; | ||
|
@@ -2003,7 +2003,7 @@ CWallet::ScanResult CWallet::ScanForWalletTransactions(const uint256& start_bloc | |
WalletLogPrintf("Scanning current mempool transactions.\n"); | ||
WITH_LOCK(cs_wallet, chain().requestMempoolTransactions(*this)); | ||
} | ||
ShowProgress(strprintf("%s " + _("Rescanning…").translated, GetDisplayName()), 100); // hide progress dialog in GUI | ||
ShowProgress(strprintf("%s %s", GetDisplayName(), _("Rescanning…").translated), 100); // hide progress dialog in GUI | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit in 4ce60d8: Could split the changes to make the format string a bit more const, and never exclusively Edit: Done in commit fa788db (and the previous commit). Feel free to rebase on them, or not, or otherwise take them, and modify them as you like. |
||
if (block_height && fAbortRescan) { | ||
WalletLogPrintf("Rescan aborted at block %d. Progress=%f\n", block_height, progress_current); | ||
result.status = ScanResult::USER_ABORT; | ||
|
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.
nit: we could avoid mentioning compile-time twice:
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 this is an improvement, I find it less clear about the distinction between the compile-time format string and the run-time string parameters, so I"m going to leave this as is for now.
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.
Not sure why it"s less clear than before, but it"s just a nit from my part anyway
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.
Agree the current message is confusing. The distinction between format string and parameters to the format string should ideally be made clearer, as well as the actual string type.
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 used
std::string
at first too, but then it was inconsistent with the rest of the documentation, which I think is even more unclear. I"ll reconsider updating allstd::string
references in this block if I have to force-push again unless you think this is blocking?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.
If
Tinyformat handles string parameters.
is too controversial, I think it can be removed in the follow-up that removes the linter.Otherwise, if this is replaced with
std::string
, someone else is going to suggest to mentionstd::string_view
as well.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.
Changing tinyformat to support
string_view
is definitely out of scope for this PR.I would at least want to make it clearer that format strings are separate from other parameters, like this or with other words to that effect:
Even though I decided to drop into l0rinc"s thread here, I independently found it unclear when doing a review-pass on it.
More precise suggestion, but not blocking:
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 agree with that, and I"ll incorporate your first suggestion (I don"t agree with the translations bit) if I have to force-push, thanks!