-
Notifications
You must be signed in to change notification settings - Fork 37.7k
refactor: remove Optional & nullopt #21415
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
Conversation
ee3dda0
to
8d20466
Compare
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.
ACK 8d20466.
Change looks correct, but now that we're using std::optional
rather than boost::optional
, we can be a lot more idiomatic. std::nullopt
almost never needs to be used explicitly - std::optional<>
objects are default initialized to std::nullopt
, std::nullopt
can be initialized with empty braces { }
, and the boolean operator can be used instead of explicit comparison with std::nullopt
.
might be worth changing the style guide -- I personally think that using nullopt is a good tradeoff between verbosity and legibility ie https://stackoverflow.com/questions/62933403/why-do-we-need-stdnullopt in many cases. |
Similar questions in a couple places today: #21407 (comment) |
Concept ACK Thanks for removing old cruft! |
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.
why no s/#include <optional.h>/#include <optional>
?
-BEGIN VERIFY SCRIPT- git rm src/optional.h sed -i -e 's/Optional</std::optional</g' $(git grep -l 'Optional<' src) sed -i -e 's/{nullopt}/{std::nullopt}/g' $(git grep -l 'nullopt' src) sed -i -e 's/ nullopt;/ std::nullopt;/g' $(git grep -l 'nullopt' src) sed -i -e 's/ nullopt)/ std::nullopt)/g' $(git grep -l 'nullopt' src) sed -i -e 's/(nullopt)/(std::nullopt)/g' $(git grep -l 'nullopt' src) sed -i -e 's/ nullopt,/ std::nullopt,/g' $(git grep -l 'nullopt' src) sed -i -e 's/? nullopt :/? std::nullopt :/g' $(git grep -l 'nullopt' src) sed -i -e 's/: nullopt}/: std::nullopt}/g' $(git grep -l 'nullopt' src) sed -i -e '/optional.h \\/d' src/Makefile.am sed -i -e '/#include <optional.h>/d' src/test/fuzz/autofile.cpp src/test/fuzz/buffered_file.cpp src/test/fuzz/node_eviction.cpp sed -i -e 's/#include <optional.h>/#include <optional>/g' $(git grep -l '#include <optional.h>' src) -END VERIFY SCRIPT-
8d20466
to
ea889a6
Compare
Similar to #21404 I've left comments where new
It was originally this way, but the duplicate include linter was unhappy. This should now be fixed. Have added some additional commits to take post-removal suggestions. |
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.
Just a couple more style comments
ea889a6
to
dca584e
Compare
I've added new includes, sorted existing includes, removed a comment and realigned other comments. |
ACK dca584e |
@@ -747,12 +747,12 @@ Optional<CNetMessage> V1TransportDeserializer::GetMessage(const std::chrono::mic | |||
HexStr(hdr.pchChecksum), | |||
m_node_id); | |||
out_err_raw_size = msg->m_raw_message_size; | |||
msg = nullopt; | |||
msg = std::nullopt; |
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.
Nit: msg.reset();
is now used on L755. Was the intention to use it also on L750?
cr ACK dca584e: patch looks correct. The AppVeyor failure looks spurious. |
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 dca584e. Kill it with fire 🔥🧨🧑🚒
inline static std::optional<int64_t> m_last_block_num_txs{}; | ||
inline static std::optional<int64_t> m_last_block_weight{}; |
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.
At first glance, I thought adding inline keyword here might cause separate m_last_block_num_txs
and m_last_block_weight
variable instances to exist in different translation units (different variables with the same name miner.cpp
and rpc/mining.cpp
that would lead to bugs), but apparently there is new linker magic in c++17 to prevent this!
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.
✨ m a g i c ✨
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.
Good to know this
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.
(more background here: #21415 (comment))
I have the same opinion about this. Using |
dca584e
to
ebc4ab7
Compare
Ok. I've dropped f603e79. |
cr ACK ebc4ab7: patch looks correct |
utACK ebc4ab7 |
Code review ACK ebc4ab7 |
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.
Posthumous ACK ebc4ab7
In bitcoin#21415 we decided to return `std::optional` rather than `{}` for uninitialized values. This PR repalces the two remaining usages of `{}` with `std::nullopt`. As a side-effect, this also quells the spurious GCC 10.2.x warning that we've had reported quite a few times. i.e bitcoin#21318, bitcoin#21248, bitcoin#20797. ```bash txmempool.cpp: In member function ‘CTxMemPool::setEntries CTxMemPool::GetIterSet(const std::set<uint256>&) const’: txmempool.cpp:898:13: warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] 898 | return {}; | ^ ```
5294f0d refactor: return std::nullopt instead of {} (fanquake) Pull request description: In #21415 [we decided](bitcoin/bitcoin#21415 (comment)) to return `std::optional` rather than `{}` for uninitialized values. This PR replaces the two remaining usages of `{}` with `std::nullopt`. As a side-effect, this also quells the spurious GCC 10.2.x warning that we've had reported quite a few times. i.e #21318, #21248, #20797. ```bash txmempool.cpp: In member function ‘CTxMemPool::setEntries CTxMemPool::GetIterSet(const std::set<uint256>&) const’: txmempool.cpp:898:13: warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] 898 | return {}; | ^ ``` ACKs for top commit: hebasto: ACK 5294f0d, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: 5b776be79ab26e5a3a5fc2b463b394ea5ce6797ed5558424873fa4ecee2898170eff76d6da9d69394d28f8f98974117fc63b922a3e19c52f5294c83073e79bb0
5294f0d refactor: return std::nullopt instead of {} (fanquake) Pull request description: In bitcoin#21415 [we decided](bitcoin#21415 (comment)) to return `std::optional` rather than `{}` for uninitialized values. This PR replaces the two remaining usages of `{}` with `std::nullopt`. As a side-effect, this also quells the spurious GCC 10.2.x warning that we've had reported quite a few times. i.e bitcoin#21318, bitcoin#21248, bitcoin#20797. ```bash txmempool.cpp: In member function ‘CTxMemPool::setEntries CTxMemPool::GetIterSet(const std::set<uint256>&) const’: txmempool.cpp:898:13: warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] 898 | return {}; | ^ ``` ACKs for top commit: hebasto: ACK 5294f0d, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: 5b776be79ab26e5a3a5fc2b463b394ea5ce6797ed5558424873fa4ecee2898170eff76d6da9d69394d28f8f98974117fc63b922a3e19c52f5294c83073e79bb0
Same rationale & motivation as #21404, which turned out to be quite low in the number of potential conflicts. Lets see what the bot has to say here.