Skip to content

Conversation

fanquake
Copy link
Member

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.

@fanquake fanquake force-pushed the remove_optional_wrapper branch 3 times, most recently from ee3dda0 to 8d20466 Compare March 11, 2021 06:34
@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 11, 2021

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, 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.

Copy link
Contributor

@jnewbery jnewbery left a 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.

@JeremyRubin
Copy link
Contributor

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.

@jonatack
Copy link
Member

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)

@practicalswift
Copy link
Contributor

Concept ACK

Thanks for removing old cruft!

Copy link
Member

@glozow glozow left a 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-
@fanquake fanquake force-pushed the remove_optional_wrapper branch from 8d20466 to ea889a6 Compare March 15, 2021 03:59
@fanquake
Copy link
Member Author

Similar to #21404 I've left comments where new Optional<> usage is being introduced. i.e here, here, here etc.

why no s/#include <optional.h>/#include ?

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.

Copy link
Contributor

@jnewbery jnewbery left a 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

@fanquake fanquake force-pushed the remove_optional_wrapper branch from ea889a6 to dca584e Compare March 15, 2021 08:48
@fanquake
Copy link
Member Author

I've added new includes, sorted existing includes, removed a comment and realigned other comments.

@jnewbery
Copy link
Contributor

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;
Copy link
Contributor

@practicalswift practicalswift Mar 15, 2021

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?

@practicalswift
Copy link
Contributor

cr ACK dca584e: patch looks correct. The AppVeyor failure looks spurious.

@DrahtBot
Copy link
Contributor

🕵️ @achow101 @sipa have been requested to review this pull request as specified in the REVIEWERS file.

Copy link
Contributor

@ryanofsky ryanofsky left a 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 🔥🧨🧑‍🚒

Comment on lines +163 to +164
inline static std::optional<int64_t> m_last_block_num_txs{};
inline static std::optional<int64_t> m_last_block_weight{};
Copy link
Contributor

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!

Copy link
Contributor

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 ✨

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know this

Copy link
Contributor

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))

@laanwj
Copy link
Member

laanwj commented Mar 16, 2021

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.

I have the same opinion about this. Using std::optional is a no-brainer but replacing nullopt with {} doesn't always seem like a readability improvement to me. {} is this kind of wildcard that can be anything from an empty structure, a default initializer, etc, nullopt is type-safe and clear.

@fanquake fanquake force-pushed the remove_optional_wrapper branch from dca584e to ebc4ab7 Compare March 17, 2021 07:04
@fanquake
Copy link
Member Author

I have the same opinion about this.

Ok. I've dropped f603e79.

@practicalswift
Copy link
Contributor

cr ACK ebc4ab7: patch looks correct

@jnewbery
Copy link
Contributor

utACK ebc4ab7

@laanwj
Copy link
Member

laanwj commented Mar 17, 2021

Code review ACK ebc4ab7

@laanwj laanwj merged commit a9d1b40 into bitcoin:master Mar 17, 2021
@fanquake fanquake deleted the remove_optional_wrapper branch March 17, 2021 11:31
Copy link
Member

@jonatack jonatack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posthumous ACK ebc4ab7

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 17, 2021
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 17, 2021
fanquake added a commit to fanquake/bitcoin that referenced this pull request Mar 22, 2021
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 {};
      |             ^
```
maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Mar 22, 2021
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
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 22, 2021
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
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants