-
Notifications
You must be signed in to change notification settings - Fork 38.7k
refactor: Replace global find_value function with UniValue::find_value method #27605
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
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. 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. |
|
Concept ACK |
|
Concept ACK. |
hebasto
left a comment
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 fa0d180f48d4e5253f58aced32768369f963d1c7, tested on Ubuntu 23.04 using GCC 13.0.1.
I think it ships with 12.2? https://packages.ubuntu.com/lunar/gcc |
stickies-v
left a comment
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 fa0d180f48d4e5253f58aced32768369f963d1c7
I can't see any behaviour change, and as far as I can tell using references in fa0d180f48d4e5253f58aced32768369f963d1c7 doesn't introduce any (potential) lifetime issues.
src/univalue/include/univalue.h
Outdated
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.
I think this should be LIFETIMEBOUND?
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.
Maybe in a follow-up for the whole univalue interface?
https://packages.ubuntu.com/lunar/g++-13 has been installed as |
|
With fa0d180f48d4e5253f58aced32768369f963d1c7 & test/interfaces_tests.cpp: In member function ‘void interfaces_tests::findCommonAncestor::test_method()’:
test/interfaces_tests.cpp:101:19: warning: possibly dangling reference to a temporary [-Wdangling-reference]
101 | const CChain& active = WITH_LOCK(Assert(m_node.chainman)->GetMutex(), return Assert(m_node.chainman)->ActiveChain());
| ^~~~~~
In file included from ./common/args.h:9,
from ./test/util/setup_common.h:9,
from test/interfaces_tests.cpp:9:
./sync.h:302:96: note: the temporary was destroyed at the end of the full expression ‘<lambda closure object>interfaces_tests::findCommonAncestor::test_method()::<lambda()>{((interfaces_tests::findCommonAncestor*)this)}.interfaces_tests::findCommonAncestor::test_method()::<lambda()>()’
302 | #define WITH_LOCK(cs, code) (MaybeCheckNotHeld(cs), [&]() -> decltype(auto) { LOCK(cs); code; }())
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
test/interfaces_tests.cpp:101:28: note: in expansion of macro ‘WITH_LOCK’
101 | const CChain& active = WITH_LOCK(Assert(m_node.chainman)->GetMutex(), return Assert(m_node.chainman)->ActiveChain());
| ^~~~~~~~~
CXX test/test_bitcoin-netbase_tests.o |
-BEGIN VERIFY SCRIPT- sed --regexp-extended -i 's/find_value\(([^ ,]+), /\1.find_value(/g' $(git grep -l find_value) -END VERIFY SCRIPT-
fa0d180 to
fa28850
Compare
This can be reverted once gcc excludes lambdas with decltype(auto) return type from its -Wdangling-reference analysis.
Might be good to ask the gcc devs if they want to fix this, as it seems a different false positive for Still, added a temporary commit here to hack around it. |
| { | ||
| auto& chain = m_node.chain; | ||
| const CChain& active = WITH_LOCK(Assert(m_node.chainman)->GetMutex(), return Assert(m_node.chainman)->ActiveChain()); | ||
| const CChain& active{*WITH_LOCK(Assert(m_node.chainman)->GetMutex(), return &Assert(m_node.chainman)->ActiveChain())}; |
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.
I think it would be best to add the commit message as code documentation to make it easier to track when this can be reverted?
I'm also not sure this commit fits the scope of the PR but I can see how it's related, and it's a separate commit anyway so probably fine.
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.
I am thinking that this may not be fixed by upstream gcc, and anyway, gcc-13.1.1 is released and will stick around, so this can't be reverted any time soon, anyway. So it might be best to just make it permanent now?
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.
GCC 13 introduced a broken behavior, and we usually do not modify our correct code to make a broken compiler happy. Considering that this is the only line in test code, I lean to agree with this change.
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.
As the test is executed in a single thread, is it a big deal to hold ::cs_main during the entire test case?
Why not to use the pattern as
bitcoin/src/test/interfaces_tests.cpp
Lines 89 to 91 in fa266c4
| LOCK(Assert(m_node.chainman)->GetMutex()); | |
| auto& chain = m_node.chain; | |
| const CChain& active = Assert(m_node.chainman)->ActiveChain(); |
bitcoin/src/test/interfaces_tests.cpp
Lines 130 to 132 in fa266c4
| LOCK(::cs_main); | |
| auto& chain = m_node.chain; | |
| const CChain& active = Assert(m_node.chainman)->ActiveChain(); |
?
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.
Likely due to a LOCKS_EXCLUDED?
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.
Likely due to a LOCKS_EXCLUDED?
Right, in Chainstate::InvalidateBlock.
hebasto
left a comment
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.
re-ACK fa266c4
|
Maybe notice the GCC-13 bug in the comments for |
I think #27605 (comment) applies and we should disable the warning instead if there are more false positives? |
|
ACK fa266c4 |
…e method Summary: These warning are very noisy and annoying when working on large refactors, hiding the useful information from the developer. Backport of [[bitcoin/bitcoin#27605 | core#27605]]. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, PiRK Reviewed By: #bitcoin_abc, PiRK Differential Revision: https://reviews.bitcoinabc.org/D15097
The global function has issues:
-Wdangling-referenceoutput #26926performance-unnecessary-copy-initializationclang-tidy isn't run on itFix all issues by making it a member function.