Constructing a temporary unnamed object only to copy or move it into a container seems both verbose in code and a strict performance penalty.
Fix both issues via the modernize-use-emplace
tidy check.
Constructing a temporary unnamed object only to copy or move it into a container seems both verbose in code and a strict performance penalty.
Fix both issues via the modernize-use-emplace
tidy check.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | Sjors, hebasto, TheCharlatan |
Concept ACK | fanquake |
Stale ACK | aureleoules |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
FundTransaction
refactor by josibake)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.
Can we do something with code like that: https://github.com/bitcoin/bitcoin/blob/db7b5dfcc502a8a81c51f56fe753990ae8b3a202/src/bitcoin-cli.cpp#L325 ?
(however, not related to this PR changes)
Can we do something with code like that:
(however, not related to this PR changes)
No. JSONRPCRequestObj
is not a constructor, but a function call, so I don’t think anything can be done there to improve anything. Also, recall that UniValue::push_back
takes an UniValue
, which avoids a copy, starting with C++17.
ACK dddd734db8140c9ae63cdbefd1f95c9f00ae5b87, I’ve followed clang-tidy’s warnings locally.
In your opinion, which value of the IgnoreImplicitConstructors
options is better/safer for us?
In your opinion, which value of the
IgnoreImplicitConstructors
options is better/safer for us?
Not sure why that option exists. Edit: Looking at the tests (clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace-ignore-implicit-constructors.cpp) and the documentation, I could not figure out the use case.
Unrelated: An emplace function is able to call explicit constructors, even though they won’t be spelled out explicitly in the source code. A push function is not able to call explicit constructors. However, if the code compiles with a push function, it should also compile with an emplace function.
utACK dddd734db8140c9ae63cdbefd1f95c9f00ae5b87
A push function is not able to call explicit constructors. However, if the code compiles with a push function, it should also compile with an emplace function.
Someone on the internet says that this ability to call explicit constructors can sometimes lead to bugs. But since everything here was first compiled with push_back
, that’s not an issue. Just something to keep an eye on for new uses of emplace_back
.
Someone on the internet says that this ability to call explicit constructors can sometimes lead to bugs. But since everything here was first compiled with
push_back
, that’s not an issue. Just something to keep an eye on for new uses ofemplace_back
.
Jup, this should only affect new code. Other things to consider: Named args and designated initializers won’t be possible with emplace. Also: Theoretically there could be resource leak, when using new
to construct an argument passed to emplace
on a container that holds smart pointers. But no new instances are introduced in this pull and fixing this issue is unrelated from this pull and already exists on current master (in tests):
0src/test/denialofservice_tests.cpp: vNodes.emplace_back(new CNode{id++,
1src/test/fuzz/coinscache_sim.cpp: caches.emplace_back(new CCoinsViewCache(&bottom, /*deterministic=*/true));
2src/test/fuzz/coinscache_sim.cpp: caches.emplace_back(new CCoinsViewCache(&*caches.back(), /*deterministic=*/true));
rebased for clang-17. Excluded nanobench for now due to it being C++11, but here it is compiled as C++17, also clang-tidy-17 introduced a new rule that requires C++20. :smiling_face_with_tear:
Should be trivial to re-ACK.
I guess the only way to fix the CI failure would be:
NOLINTNEXTLINE
Example of the CI error:
0clang-tidy-17 -p=/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu -quiet -load=/tidy-build/libbitcoin-tidy.so /ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/script/signingprovider.cpp
1script/signingprovider.cpp:371:41: error: unnecessary temporary object created while calling emplace_back [modernize-use-emplace,-warnings-as-errors]
2 371 | if (track) node.leaves.emplace_back(LeafInfo{.script = std::vector<unsigned char>(script.begin(), script.end()), .leaf_version = leaf_version, .merkle_branch = {}});
3 |
Fix the bug in clang-tidy-17
Is there an upstream issue?
NOLINTNEXTLINE
exists, so I used that.
367@@ -368,6 +368,7 @@ TaprootBuilder& TaprootBuilder::Add(int depth, Span<const unsigned char> script,
368 /* Construct NodeInfo object with leaf hash and (if track is true) also leaf information. */
369 NodeInfo node;
370 node.hash = ComputeTapleafHash(leaf_version, script);
371+ // NOLINTNEXTLINE(modernize-use-emplace)
7@@ -8,6 +8,8 @@
8 "src/crypto/ctaes",
9 "src/leveldb",
10 "src/minisketch",
11+ "src/bench/nanobench.cpp",
12+ "src/bench/nanobench.h",