Benefits:
- Type-safe
- Mockable
- Allows to revert a temporary test workaround
Benefits:
This allows to revert the temporary commit
0bfb9208df556f77cddfedfd73e5811a0e031d34 (test: fix test failures in
test/functional/p2p_timeouts.py).
-BEGIN VERIFY SCRIPT-
ren() { sed -i "s/\<$1\>/$2/g" $( git grep -l "$1" ./src/ ) ; }
ren nLastBlockTime m_last_block_time
ren nLastTXTime m_last_tx_time
ren nTimeConnected m_connected
-END VERIFY SCRIPT-
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
4336@@ -4335,7 +4337,7 @@ void PeerManagerImpl::CheckForStaleTipAndEvictPeers()
4337
4338 int64_t time_in_seconds = GetTime();
0 auto time_in_seconds = GetTime<std::chrono::seconds>();
1
2 EvictExtraOutboundPeers(time_in_seconds);
Concept ACK
time_init
and time_later
to SetMockTime
in src/test/denialofservices_tests.cpp
file. I have checked that these variables are used to SetMockTime
at appropriate places.
However, I am not proficient enough (yet) to comment on if this fixes the bug that was initially described in #23739I have some suggestions:
src/test/net_peer_eviction_tests.cpp
is touched in this PR, how about adding the clang formatting changes suggested by :arrow_down_small: to this PR itself.0git diff -U0 HEAD~1.. | ./contrib/devtools/clang-format-diff.py -p1 -i -v
Since the file src/test/net_peer_eviction_tests.cpp is touched in this PR, how about adding the clang formatting changes suggested by arrow_down_small to this PR itself.
Looks like this will cause re-formats of lines in the file I haven’t touched? Also, I think the file will/might be touched soon by other PRs, so I want to minimize the conflicts for now. Maybe it can be formatted in a pull that touches those lines directly?
ACK fad943821e35d0eb2143061e718f0193e12a4c71
The diff as suggested wouldn’t compile and needs more changes, so I’ll leave it for a follow-up.
I wasn’t aware of this. How about leaving a comment above this line explaining the needed follow-up.
Maybe it can be formatted in a pull that touches those lines directly?
Formatting can be taken up as a direct follow-up to this PR as soon as this one gets merged.
I wasn’t aware of this. How about leaving a comment above this line explaining the needed follow-up.
Personally I am not a fan of adding comments to source code to list future refactoring that can be done. I think if it is worth it, it should be done in a pull request (or an issue created to track it).
Do you want to work on that?
Do you want to work on that?
I think I can give it a try!
I think I can give it a try!
Nice. Let me know if you have any questions. If not, you can also ping me for review.
The purpose of this PR is not renaming variables; the point is moving to more type-safe representation of time.
When code is being changed already, the developer guidelines state that the new code should follow the style guidelines, and that’s what is happening here.
Furthermore, in this specific case it also makes the change more reviewable. By changing the name, you know every access site is updated.