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.
That should be the first to be checked.
There was a problem hiding this comment.
I agree and have moved it up.
| # if __has_cpp_attribute (noreturn) | ||
| # define NORETURN [[noreturn]] | ||
| # endif | ||
| #endif |
There was a problem hiding this comment.
I would prefer if we keep the #else at the end.
There was a problem hiding this comment.
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.
Right, but how do we handle the case of a compiler which supports
__has_cpp_attributebut 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.
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.
I'm not sure I got your idea. Just setting a different '#define' for whether
__has_cpp_attributeis 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.
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.
#endifThere was a problem hiding this comment.
Hmm that's not standard compliant code, is it? I'd be careful defining symbols starting with "__".
There was a problem hiding this comment.
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.
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 #defines 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)