Skip to content

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Nov 15, 2022

The UNREACHABLE macro was suggested in #24812, but during reviewing it has been dropped:

This is unused and on a second thought I wonder if there is any value in it. The current code can already use assert(false) just fine. Introducing another way to write assert(false) will just lead to bike-shedding without any benefit.

This macro prevents compiler warnings -- -Wreturn-type (GCC) and C4715 (MSVC) -- when building for/on Windows.

@hebasto
Copy link
Member Author

hebasto commented Nov 15, 2022

cc @aureleoules @MarcoFalke

@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 16, 2022

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

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept NACK fanquake
Concept ACK aureleoules, MarcoFalke

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #27385 (net, refactor: extract Network and BIP155Network logic to node/network by jonatack)
  • #27231 (Fix logging RPC and -debugexclude with 0/none values, add test coverage, improve docs by jonatack)
  • #26697 (logging: use bitset for categories by LarryRuane)

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.

@aureleoules
Copy link
Contributor

Concept ACK

@fanquake
Copy link
Member

~0 - agree with the earlier discussion in #24812. Why do we need to redefine assert(), because Windows compilers are broken? We'll have an unintuitive split where assert() is used, except in a switch, because we're trying to suppress randomly (the warnings aren't emitted consistently from switches with mingw-w64) happening warnings.

This will be another thing developers have to look up, rather than seeing assert(), and knowing what it means.

If we were going to introduce an unreachable macro, we could at least use __builtin_unreachable (GCC, Clang, ICC). Of course MSVC doesn't implement that, and instead has __assume() (not to be confused with our own Assume()).

@hebasto
Copy link
Member Author

hebasto commented Nov 16, 2022

because Windows compilers are broken

They are not broken, as they do not violate the C++ standard. Of course, the way how they consider warnings for int f(){ assert(false); } differs from other popular compilers.

We'll have an unintuitive split where assert() is used, except in a switch, because we're trying to suppress randomly (the warnings aren't emitted consistently from switches with mingw-w64) happening warnings.

For non-Windows targets warnings are inconsistent between GCC and Clang as well (remove assert(false); statement to see it).

If we were going to introduce an unreachable macro, we could at least use __builtin_unreachable (GCC, Clang, ICC). Of course MSVC doesn't implement that, and instead has __assume() (not to be confused with our own Assume()).

That could be like an implementation of std::unreachable from C++23.

But the suggested macro is safer when it comes to handle, for example, non-defined-explicitly enumeration values, as std::abort is better than UB.

@hebasto
Copy link
Member Author

hebasto commented Nov 16, 2022

Updated 05ffaf4 -> 39d681e (pr26504.01 -> pr26504.02):

@@ -695,7 +696,7 @@ uint32_t CNetAddr::GetLinkedIPv4() const
// Teredo tunneled IPv4: the IPv4 address is in the last 4 bytes of the address, but bitflipped
return ~ReadBE32(Span{m_addr}.last(ADDR_IPV4_SIZE).data());
}
assert(false);
UNREACHABLE();
Copy link
Member

Choose a reason for hiding this comment

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

This is now also changing code that does not use switch statements, and I assume doesn't warn under mingw-w64, becoming inconsistent with the rest of the codebase. If we are going to change some of these, we should be changing all, otherwise this is just random refactoring.

Copy link
Member Author

Choose a reason for hiding this comment

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

I assume doesn't warn under mingw-w64

It does when compiling with -O0.

Copy link
Member

Choose a reason for hiding this comment

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

There'd be test/lint/lint-assertions.py if this is a goal

Copy link
Member Author

Choose a reason for hiding this comment

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

@fanquake

we should be changing all, otherwise this is just random refactoring.

In that case, what macro name could be appropriate?

@hebasto
Copy link
Member Author

hebasto commented Nov 16, 2022


void unreachable_fail(const char* file, int line, const char* func)
{
std::cerr << strprintf("Internal bug detected: Unreachable code reached (fatal, aborting)\n%s:%d (%s)\nPlease report this issue here: %s\n", file, line, func, PACKAGE_BUGREPORT) << std::endl;
Copy link
Member

@maflcko maflcko Dec 10, 2022

Choose a reason for hiding this comment

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

could rebase and use the existing string template?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@hebasto
Copy link
Member Author

hebasto commented Dec 10, 2022

Updated dd47e2a -> 426d6be (pr26504.03 -> pr26504.04):

To make this PR compatible with the recently merged #26645, the CopyrightHolders() and LicenseInfo() functions have been moved from clientversion.{h,cpp}' to util/string.{h,cpp}.

@hebasto
Copy link
Member Author

hebasto commented Dec 12, 2022

Rebased on top of the #26688 and drafted until the latter is being reviewed.

@maflcko
Copy link
Member

maflcko commented Jul 14, 2023

Concept ACK on UNREACHABLE. I find it frustrating to play compiler golf against g++ in the CI on every code push that uses a switch-case on an enum class.

First push is -Werror=return-type, the second push is Assert(false);, but g++ failing to understand it, then the third push is assert(false);

Co-authored-by: Aurèle Oulès <aurele@oules.com>
Co-authored-by: MacroFake <falke.marco@gmail.com>
@maflcko
Copy link
Member

maflcko commented Jul 14, 2023

@hebasto Let us know if you'll pick this up again or if you want someone else to do it?

@hebasto
Copy link
Member Author

hebasto commented Jul 14, 2023

@hebasto Let us know if you'll pick this up again or if you want someone else to do it?

Almost ready :)

@hebasto
Copy link
Member Author

hebasto commented Jul 14, 2023

re #26504 (comment)

Maybe drop this change and the one to src/script/interpreter.cpp for now and only use the second and third commit?

Done. Rebased.

@hebasto hebasto marked this pull request as ready for review July 14, 2023 13:21
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

Nice. Review lgtm

@maflcko
Copy link
Member

maflcko commented Jul 14, 2023

Looks like you forgot to include the doc change? abacaef#diff-5e319039d67254bed6ca82562ec5f560f102004aa4806e4ca77f5d0065c65fbb

Also, could update title, description and commit message?

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.

If this is done, IIUC the developer notes should be updated.

@@ -12,6 +12,7 @@
#include <logging.h>
#include <tinyformat.h>
#include <util/chaintype.h>
#include <util/check.h>
Copy link
Member

@jonatack jonatack Jul 14, 2023

Choose a reason for hiding this comment

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

A potential downside with this change is the util/check.h code is added to a fair number of compilation units (unless the header was already missing). Also, it looks like some cases haven't been updated. Maybe only use it for new or touched code going forward?

This change prevents `-Wreturn-type` and `C4715` warnings when building
for/on Windows.
@hebasto hebasto changed the title Add UNREACHABLE macro and drop -Wreturn-type/C4715 warnings suppressions Add UNREACHABLE macro Jul 14, 2023
@hebasto
Copy link
Member Author

hebasto commented Jul 14, 2023

@MarcoFalke

Also, could update title, description and commit message?

The title an the description have been updated. What update for commit messages would you like to see?

@fanquake
Copy link
Member

fanquake commented Jul 14, 2023

Apparently, this macro prevents compiler warnings

Either it does or it doesn't? If it does, then any workarounds should be removed, and warnings re-enabled.

If it doesn't, there's no point to this refactoring at all, if it doesn't even acheive the stated goals.

I find it frustrating to play compiler golf against g++ in the CI on every code push that uses a switch-case on an enum class.

Which CI is this? The only one where it is an issue has the warnings disabled?

@maflcko
Copy link
Member

maflcko commented Jul 14, 2023

Which CI is this? The only one where it is an issue has the warnings disabled?

I don't use g++, nor Windows, locally, so this is a general problem of not knowing which function is marked noreturn by g++ or msvc internally. Having a macro that is known to work on all compilers is helpful, I think.

I don't care about updating the existing code, but I think having a macro for those that find it helpful, can't hurt, can it?

@fanquake
Copy link
Member

but I think having a macro for those that find it helpful, can't hurt, can it?

I agree that having a macro could be useful.

Separately, note that upstream, the missing noreturn attributes have been added to assert in the mingw-w64 headers, mingw-w64/mingw-w64@1690994, so beginning with 11.0.0, there are no-longer -Wreturn-type warnings with assert(false) usage. See #28092 where I've updated the docs.

@fanquake
Copy link
Member

I don't care about updating the existing code,

To be clear, I agree, and am still a NACK to any code changes here.

@hebasto hebasto closed this Jul 20, 2023
@bitcoin bitcoin locked and limited conversation to collaborators Jul 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants