test/fuzz/banman.cpp:35:13: warning: unused function 'operator==' [-Wunused-function]
static bool operator==(const CBanEntry& lhs, const CBanEntry& rhs)
^
1 warning generated.
See #22517 (comment)
test/fuzz/banman.cpp:35:13: warning: unused function 'operator==' [-Wunused-function]
static bool operator==(const CBanEntry& lhs, const CBanEntry& rhs)
^
1 warning generated.
See #22517 (comment)
See #22517 (comment)
Actually, I mentioned it expecting no one will silent a temporary warning :smile:
No strong opinion on this. It will be interesting to see the response to this.
Do we want to have a policy of silencing temporary warnings when their is a clear plan that will silence them? --- this warning will be silenced when the fix for the banman fuzz test is implemented.
On the other hand, the argument could be made that #22517 should not have allowed this warning to come up and this PR can be seen as a follow-up to that PR. A followup which finishes properly temporarily disabling the assert.
Tested that this silences the warning on Ubuntu 20.04: master:
$ make 2>&1 > /dev/null | grep -o "Wunused-function" | wc -l
1
pr:
$ make 2>&1 > /dev/null | grep -o "Wunused-function" | wc -l
0
This warning disturbs developers' workflow (compilation with -Werror fails).
It does not matter whether it is temporary, semi-temporary, permanently-temporary, temo-low or should just be painted in purple color.
cr ACK 83dd35260b30eaedc8822326f75c037d5e51f883
Sorry didn't see the warning in my patch
```
test/fuzz/banman.cpp:35:13: warning: unused function 'operator==' [-Wunused-function]
static bool operator==(const CBanEntry& lhs, const CBanEntry& rhs)
^
1 warning generated.
```114 | @@ -109,8 +115,9 @@ FUZZ_TARGET_INIT(banman, initialize_banman) 115 | BanMan ban_man_read{banlist_file, /* client_interface */ nullptr, /* default_ban_time */ 0}; 116 | banmap_t banmap_read; 117 | ban_man_read.GetBanned(banmap_read); 118 | - // Temporarily disabled to allow the remainder of the fuzz test to run while a fix is being worked on: 119 | - // assert(banmap == banmap_read); 120 | +#ifdef ENABLE_BANMAN_COMPARE 121 | + assert(banmap == banmap_read);
nit: wouldn't it be easier to just:
(void)(banmap == banmap_read);
Yes, that is shorter, thanks!
83dd35260b...787296eb67: take review suggestion
ACK 787296eb6744b15ab693c053e4030ff68dfc95e0
I don't think we need to follow every temporary change with a change to clean up warnings. If there is intent to use this function soon, I do not see the point of merging an intermediate PR that removes it just to be reintroduced.
Edit: oh, you didn't remove it. This seems fine to me (though still I don't think we should be too busybody about this).
cr ACK 787296eb6744b15ab693c053e4030ff68dfc95e0
again my fault for not noticing the compiler warning in the initial patch
cr ACK 787296eb6744b15ab693c053e4030ff68dfc95e0
~Backported in #22629.~
UPDATE: #22629 (comment)