Globals: Explicitly pass const CChainParams& to UpdateTip() #7876

1. 
   jtimon commented at 1:14 pm on April 14, 2016: contributor

   Part of #7829.
2. Globals: Explicitly pass const CChainParams& to UpdateTip() 145ae6e714
3. laanwj added the label Refactoring on Apr 14, 2016
4. 
   laanwj commented at 1:25 pm on April 14, 2016: member

   utACK https://github.com/bitcoin/bitcoin/pull/7876/commits/145ae6e714f9f212c39ec7684b4de813e0abc921

   If there are other functions where you can easily pass in CChainParams& with low impact to the rest of the code (e.g. like #7828), I’d prefer if you combine them into this as multiple commits instead of open separate pulls.

5. 
   instagibbs commented at 2:06 pm on April 14, 2016: member

   utACK https://github.com/bitcoin/bitcoin/pull/7876/commits/145ae6e714f9f212c39ec7684b4de813e0abc921
6. 
   jtimon commented at 4:22 pm on April 14, 2016: contributor

   @laanwj well, the idea of #7829 is helping new people doing them. I did #7828 as a “canonical example” (in fact, I wanted to pass CPolicy at the same time, but ProcessMessage() has waited enough for CPolicy to exist…) and this one because it seems slightly more confusing (or could confuse someone trying to do it for DisconnectTip()). I wouldn’t mind doing DisconnectTip() in this PR for that reason.

   Probably the less disruptive remaining ones are ConnectBlock(), CheckBlockHeader() and ContextualCheckBlockHeader() [I didn’t put ContextualCheckBlock() because @morcos and I want to just destroy the function]. But these seem good exercises for #7829.

   Besides that, I must have tried to do CheckBlockHeader() like in 10 different PRs already (probably 5 of them did it before and 5 of them after the cursed consensus moveonly), but I’ve never tried to get someone else to do it. Perhaps this breaks the curse or something.

7. 
   laanwj commented at 6:49 am on April 15, 2016: member

   @jtimon Well sure it helps reviewing to have small pull requests, but if it’s just adding an argument to a function and passing it on that’s hardly a risky refactor, nor controversial in any way.

   I wouldn’t mind doing DisconnectTip() in this PR for that reason

   ok Let’s do that.

8. 
   jtimon commented at 1:31 pm on April 20, 2016: contributor

   Closing in favor of #7916 , which contains this same commit plus another one doing it for DisconnectTip() and InvalidateBlock() too.
9. jtimon closed this on Apr 20, 2016

   ---

10. DrahtBot locked this on Sep 8, 2021

Contributors
jtimon laanwj instagibbs

Labels
Refactoring