-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Minor: fix msvc warning "not all control paths return a value" #5650
Conversation
When building with /Od - default cmake debug build for me, the __assume(false); trick does not work to get rid of the C4714 warnings https://godbolt.org/z/a6xGnfP7d D:\tmp\cppcheck\lib\keywords.cpp(205): warning C4715: 'Keywords::getOnly': not all control paths return a value D:\tmp\cppcheck\lib\keywords.cpp(226): warning C4715: 'Keywords::getOnly': not all control paths return a value D:\tmp\cppcheck\lib\keywords.cpp(168): warning C4715: 'Keywords::getAll': not all control paths return a value D:\tmp\cppcheck\lib\keywords.cpp(188): warning C4715: 'Keywords::getAll': not all control paths return a value Proposed fix: also define NORETURN to [[noreturn]] when according to __has_cpp_attribute [[noreturn]] is supported https://en.cppreference.com/w/cpp/feature_test (For previous discussion see also danmar#5497)
lib/config.h
Outdated
@@ -57,7 +57,12 @@ | |||
# define NORETURN [[noreturn]] | |||
#elif defined(__GNUC__) | |||
# define NORETURN __attribute__((noreturn)) | |||
#else | |||
#elif defined __has_cpp_attribute |
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.
That should be the first to be checked.
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 agree and have moved it up.
# if __has_cpp_attribute (noreturn) | ||
# define NORETURN [[noreturn]] | ||
# endif | ||
#endif |
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 would prefer if we keep the #else
at the end.
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.
Right, but how do we handle the case of a compiler which supports __has_cpp_attribute
but for which __has_cpp_attribute (noreturn)
is false? I don't know that such a case exists but I wouldn't want to assume it does not.
The __has_pp_attribute(noreturn)
check has to be guarded by a defined __has_cpp_attribute
check if you don't want to trip up compilers which don't support __has_cpp_attribute.
https://godbolt.org/z/je4jM6W3h
That's why I think we either have to duplicate code in the #else
for if __has_cpp_attribute (noreturn)
or go the !defined(NORETURN)
route.
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.
Right, but how do we handle the case of a compiler which supports
__has_cpp_attribute
but for which__has_cpp_attribute (noreturn)
is false?
This comment is indeed in contradiction with my other comment. I realized it myself shortly after I wrote it.
But we could move the check for __has_cpp_attribute
out and set a different define we check in addition. That would avoid potential duplicate code if we need to check a feature in another place.
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.
You mean like
#if defined(__has_cpp_attribute)
# if __has_cpp_attribute (noreturn)
# define HAS_ATTRIB_NORETURN
# endif
#endif
#if defined(HAS_ATTRIB_NORETURN)
# define NORETURN [[noreturn]]
#elif ...
# ...
If that's what you meant, I fail to see a benefit but it would work fine as well. If you feel strongly about it, I'll modify it like that.
If you meant something else, could you please clarify? I'm not sure I got your idea. Just setting a different '#define' for whether __has_cpp_attribute
is supported would not help with the syntax error in __has_cpp_attribute (noreturn)
when it's not supported.
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'm not sure I got your idea. Just setting a different '#define' for whether
__has_cpp_attribute
is supported would not help with the syntax error in__has_cpp_attribute (noreturn)
when it's not supported.
Ah right. I forgot about this annoying quirk. As I mentioned my experiences with post-c+11 code bases are few.
If you feel strongly about it, I'll modify it like that.
I don't.
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 the kind of solution I was looking for was something we already use in sourcelocation.h
:
#ifndef __has_builtin
#define __has_builtin(x) 0 // Compatibility with non-clang compilers.
#endif
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.
Hmm that's not standard compliant code, is it? I'd be careful defining symbols starting with "__".
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 has nothing to do with the standard but __
macros are reserved and should not be specified by user code. It did not cause any Clang (I think -Wreserved-macro-identifier
covers this) or clang-tidy warnings, so I guess it is fine. Maybe the #ifndef
instead of just defining it unconditionally.
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 admit that the following is only language lawyer nitpicking and I think we'll be fine in practice the way cppcheck is now using it. But if you feel like reading an argument partly against it anyway, here it goes:
Yes, I think you're not getting the reserved identifier warning because you're testing with a clang version that supports __has_builtin
and you are not defining the identifier because it is #ifndef
'ed out. Clang does warn about reserved-macro-identifier when such a define takes place: https://godbolt.org/z/jhEK5vT8E
A program which #define
s an identifier with __
breaks a shall rule with no diagnostic required (https://eel.is/c++draft/lex.name#3 https://eel.is/c++draft/intro.compliance#general-2.2). TIL there's even a clause specifically forbidding __has_cpp_attribute
in anything but a preprocessor check (https://eel.is/c++draft/cpp.cond#7).
Standard library implementations also do work with those identifiers but I did not find a case that you'd be breaking by defining them like you're doing.
I actually came across a case just like ours on isocpp.org. Still to my understanding it's not in line with the letter of the standard.
Thanks for your contribution. I realized this as well a while ago as well but I didn't act on it since I wanted to have a build which fail on the compiler warnings first so we don't keep regressing on it. But as I still finishing up me more major tasks I haven't done so. |
Moved __has_cpp_attribute block up to first choice. When we have a portable standard way of expressing it, that's the best choice. (Addresses Review Feedback from Firewave)
When building with /Od - default cmake debug build for me, the __assume(false); trick does not work to get rid of the C4714 warnings
https://godbolt.org/z/a6xGnfP7d
D:\tmp\cppcheck\lib\keywords.cpp(205): warning C4715: 'Keywords::getOnly': not all control paths return a value
D:\tmp\cppcheck\lib\keywords.cpp(226): warning C4715: 'Keywords::getOnly': not all control paths return a value
D:\tmp\cppcheck\lib\keywords.cpp(168): warning C4715: 'Keywords::getAll': not all control paths return a value
D:\tmp\cppcheck\lib\keywords.cpp(188): warning C4715: 'Keywords::getAll': not all control paths return a value
Proposed fix: also define NORETURN to [[noreturn]] when according to __has_cpp_attribute [[noreturn]] is supported https://en.cppreference.com/w/cpp/feature_test
(For previous discussion see also #5497)