[llvm-bugs] [Bug 50046] New: Pedantically warning on attributes used as extensions

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50046

            Bug ID: 50046
           Summary: Pedantically warning on attributes used as extensions
           Product: clang
           Version: 11.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: barry.revzin at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Consider the following code, which tries to detect the ability to use
[[nodiscard]] and then uses it:

#ifndef __has_cpp_attribute
#  define HAS_ATTRIBUTE(x) 0
#else
#  define HAS_ATTRIBUTE(x) __has_cpp_attribute(x) > 0
#endif

#if HAS_ATTRIBUTE(nodiscard)
#  define NODISCARD [[nodiscard]]
#else
#  define NODISCARD
#endif

struct NODISCARD Result { };

With clang (on any version I've tested), if I compile this with -std=c++14
-pedantic, I get a warning:

<source>:13:8: warning: use of the 'nodiscard' attribute is a C++17 extension
[-Wc++17-extensions]
struct NODISCARD Result { };
       ^
<source>:8:23: note: expanded from macro 'NODISCARD'
#  define NODISCARD [[nodiscard]]
                      ^

But if __has_cpp_attribute(nodiscard) is not the right way to detect nodiscard,
what would be?

One alternative might be to use __cplusplus somehow to check to see if the
attribute is *really* available. That is, do this:

#  define HAS_ATTRIBUTE(x) __has_cpp_attribute(x) > 0 && __has_cpp_attribute(x)
> 0 && __cplusplus >= __has_cpp_attribute(x)

This has the benefit of silencing the pedantic warning.

But it also has the consequence of actually not using [[nodiscard]] even when
it's available. For instance, on clang trunk 11.0.0, when compiling with
-std=c++17, __cplusplus is 201703 but __has_cpp_attribute(nodiscard) is 201907.
As a result, my Result here would not be [[nodiscard]] - a false negative.
clang 11.0 --std=c++20 would successfully mark Result as [[nodiscard]], but gcc
10.2 --std=c++20 would not (because that release does not yet increase
__cplusplus).

Is there a way to programmatically detect the availability of an attribute in a
way that would not be warned? Maybe that means __has_cpp_attribute(nodiscard)
should be 0 if compiling as --std=c++14 or --std=c++11 with -pedantic and
without -Wno-c++17-extensions? Otherwise, the only solution I think would be to
do what nlohmann/json did (https://github.com/nlohmann/json/issues/1535) and do
something like this:

#if __has_cpp_attribute(nodiscard)
    #if defined(__clang__) && !defined(JSON_HAS_CPP_17) // issue #1535
        #define JSON_NODISCARD
    #else
        #define JSON_NODISCARD [[nodiscard]]
    #endif
#endif

But this kind of explicit compiler-based configuration was what we were hoping
to avoid with feature-test macros (and also means that clang users that are not
compiling with -pedantic still don't get nodiscard).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210420/e3e5fb6b/attachment.html>