Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Minor: fix msvc warning "not all control paths return a value" #5650

Merged
merged 4 commits into from
Nov 12, 2023
Merged

Minor: fix msvc warning "not all control paths return a value" #5650

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
79b6525
Minor: fix msvc warning "not all control paths return a value"
StefanVK Nov 11, 2023
9d2d226
Merge branch 'danmar:main' into fix_noreturn_msvc_warning
StefanVK Nov 11, 2023
7bcdf4a
Minor: fix msvc warning "not all control paths return a value"
StefanVK Nov 12, 2023
b3e07d4
Fix formatting / run uncrustify
StefanVK Nov 12, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion lib/config.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,12 @@
# define NORETURN [[noreturn]]
#elif defined(__GNUC__)
# define NORETURN __attribute__((noreturn))
#else
#elif defined __has_cpp_attribute
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

@StefanVK StefanVK Nov 12, 2023 •
edited
Loading

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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

Copy link
Contributor Author

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 "__".

Copy link
Collaborator

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.

Copy link
Contributor Author

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 #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.

#if !defined(NORETURN)
# define NORETURN
#endif

Expand Down
Loading