-
Notifications
You must be signed in to change notification settings - Fork 37.4k
refactor: Remove almost all validation option globals #25704
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
The head ref may contain hidden characters: "2207-val-globals-\u{1F4A7}"
Conversation
nice, Concept ACK |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
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.
Code review ACK fa82b44
fa82b44
to
fa3cac2
Compare
Seeing conflicts with a couple kernel PRs, so pinging @dongcarl to see if this interferes with anything |
33ea57b
to
fa78faa
Compare
Concept and light Code Review ACK, very satisfying PR. |
Code Review ACK fa738b8 Shuffling between Followups:
Marco: Any reason these commits are "Unverified"? |
fa78faa
to
fa68b9e
Compare
Good idea.
Yes, this is a stick I threw in the mud so that you can't trust Microsoft/GitHub to mark my commits as verified. If you care about this, you can verify it locally, but it seems no one does that anyway. |
fa68b9e
to
fa39cf8
Compare
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.
Code review ACK fa227bd. Left some suggestions, but could be merged as-is.
Main change since last review is rebasing and making assumed valid block, minimum chain work, and check block index options in kernel API match bitcoind defaults, using std::optional
type and a Flatten
function.
(Flatten
isn't my favorite approach but it solves problem of making kernel API straightforward to use and having kernel API defaults match bitcoind defaults. Preferred approach to doing this would have been to keep m_options fixed and just add accessor methods to merge option values and runtime defaults on demand. But difference between the approaches are internal to ChainManager, so not very significant.)
fa227bd
to
fa76987
Compare
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.
Code review ACK fa76987. Just suggested code and comment cleanups since last review, and moving the -minimumchainwork check back to AppInitParameterInteraction, before daemonization.
This changes the assumed valid block for the bitcoin-chainstate executable. Previously it was uint256{}, now it is defaultAssumeValid.
This changes the minimum chain work for the bitcoin-chainstate executable. Previously it was uint256{}, now it is the chain's default minimum chain work.
This changes the flag for the bitcoin-chainstate executable. Previously it was false, now it is the chain's default value (still false for the main chain).
fa76987
to
aaaa7bd
Compare
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.
Code review ACK aaaa7bd. No changes since last review, other than rebase
Concept ACK |
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.
reACK aaaa7bd
Concept ACK, will try to review today or tomorrow. |
Code review ACK aaaa7bd |
GCC throws multiple |
Which version of GCC and what are the steps to reproduce? |
Debian 11 + gcc 10.2, Ubuntu 22.04 gcc 11.3:
|
Thanks, fixed in #26409 |
There was a bug in here, though I certainly don't think I would have caught it: #26477 |
It seems preferable to assign globals to a class (in this case
ChainstateManager
), than to leave them dangling. This should clarify scope for code-readers, as well as clarifying unit test behaviour.