0test/fuzz/banman.cpp:35:13: warning: unused function 'operator==' [-Wunused-function]
1static bool operator==(const CBanEntry& lhs, const CBanEntry& rhs)
2 ^
31 warning generated.
See #22517 (comment)
0test/fuzz/banman.cpp:35:13: warning: unused function 'operator==' [-Wunused-function]
1static bool operator==(const CBanEntry& lhs, const CBanEntry& rhs)
2 ^
31 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:
0$ make 2>&1 > /dev/null | grep -o "Wunused-function" | wc -l
1
21
pr:
0$ make 2>&1 > /dev/null | grep -o "Wunused-function" | wc -l
1
20
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:
0 (void)(banmap == banmap_read);
83dd35260b...787296eb67
: take review suggestion
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
~Backported in #22629.~
UPDATE: #22629 (comment)