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.

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

[Clang] warning: use of the 'nodiscard' attribute is a C++17 extension [-Wc++17-extensions] #1535

Closed
past-due opened this issue Mar 20, 2019 · 4 comments · Fixed by #1551
Closed
Assignees
Labels
confirmed kind: bug release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@past-due
Copy link
Contributor

  • What is the issue you have?

When compiling on Clang (tested 3.9.1 - 7.0.0) with the following compiler flags:
-Wpedantic -std=c++11

Clang displays warnings about:
warning: use of the 'nodiscard' attribute is a C++17 extension [-Wc++17-extensions]

Full log:

json.hpp:13087:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:14262:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:14306:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:18858:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19627:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19643:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19736:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19752:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19824:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19840:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19911:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:19927:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
json.hpp:20516:5: error: use of the 'nodiscard' attribute is a C++17 extension [-Werror,-Wc++17-extensions]
    JSON_NODISCARD
    ^
json.hpp:496:34: note: expanded from macro 'JSON_NODISCARD'
        #define JSON_NODISCARD [[nodiscard]]
                                 ^
13 errors generated.
  • Please describe the steps to reproduce the issue. Can you provide a small but working code example?

Compile json.hpp (3.6.1) using Clang (tested 3.9.1 - 7.0.0) with the following compiler flags:
-Wpedantic -std=c++11

  • What is the expected behavior?

Compilation succeeds without error / warning?

  • And what is the actual behavior instead?

See above.

Clang (tested 3.9.1 - 7.0.0)

  • Did you use a released version of the library or the version from the develop branch?

Release 3.6.1

@nlohmann
Copy link
Owner

The library checks whether the nodiscard attribute is available. Apparently, Clang reports it being available in C++11 mode, but then -Wc++17-extensions warns that it is a C++17 feature. This seems odd.

A solution could be to make the check more restrictive and switch off nodiscard unless C++17 is detected. I don't really like this. Alternatively, we could suppress the warning in the library. This is also not nice... Any opinions?

@nlohmann nlohmann added state: please discuss please discuss the issue or vote for your favorite option confirmed labels Mar 20, 2019
@past-due
Copy link
Contributor Author

A solution could be to make the check more restrictive and switch off nodiscard unless C++17 is detected. I don't really like this.

Me neither.

Alternatively, we could suppress the warning in the library. This is also not nice... Any opinions?

At the moment, I'm leaning towards this second option, but I'm eager to hear what others think.

As a note, using:

#pragma clang diagnostic ignored "-Wc++1z-extensions"

Will cover earlier Clang versions that only support -Wc++1z-extensions, and is an alias for -Wc++17-extensions on newer Clang versions.

@heavywatal
Copy link
Contributor

The downside of the first option seems more acceptable to me in the long run.

If the first option is taken, the clang users with -std=c++11/c++14 cannot enjoy warnings from [[nodiscard]]. It should be fine because nodiscard is supposed to be available since c++17. Users have an option to use -std=c++17 if they really want it.

If the second option is taken, the developers of this library cannot enjoy warnings from -Wc++17-extensions. It potentially makes the development process more error prone.

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

heavywatal added a commit to heavywatal/nlohmann-json that referenced this issue Mar 28, 2019
- Switch off `nodiscard` for clang unless C++17 is detected.
- Detect C++ standard before the switch.
nlohmann added a commit that referenced this issue Mar 29, 2019
Remove C++17 extension warning from clang; #1535
@nlohmann nlohmann added solution: proposed fix a fix for the issue has been proposed and waits for confirmation and removed state: please discuss please discuss the issue or vote for your favorite option labels Mar 29, 2019
@nlohmann nlohmann self-assigned this Mar 29, 2019
@nlohmann nlohmann added this to the Release 3.6.2 milestone Mar 29, 2019
@nlohmann
Copy link
Owner

🔖 release item in #1551.

@nlohmann nlohmann modified the milestones: Release 3.6.2, Release 3.7.0 Jul 9, 2019
@nlohmann nlohmann added this to the Release 3.7.0 milestone Jul 28, 2019
tanzislam added a commit to tanzislam/cryptopals that referenced this issue Sep 4, 2024
google/googletest@5a37b517ad introduced a check on `__has_cpp_attribute(maybe_unused)`. Under Clang this is true even in `-std=c++14` mode, but subsequently the use of the `[[maybe_unused]]` attribute triggers a `-Wc++17-extensions` warning (which we elevate to an error via `-pedantic-errors`).

This is observed in the macOS Travis CI environment, where we use Apple Clang: https://app.travis-ci.com/github/tanzislam/cryptopals/jobs/625697125

A similar Clang issue with a different C++17 attribute was also observed in nlohmann/json#1535.
tanzislam added a commit to tanzislam/cryptopals that referenced this issue Oct 12, 2024
google/googletest@5a37b517ad introduced a check on `__has_cpp_attribute(maybe_unused)`. Under Clang this is true even in `-std=c++14` mode, but subsequently the use of the `[[maybe_unused]]` attribute triggers a `-Wc++17-extensions` warning (which we elevate to an error via `-pedantic-errors`).

This is observed in the macOS Travis CI environment, where we use Apple Clang: https://app.travis-ci.com/github/tanzislam/cryptopals/jobs/625697125

A similar Clang issue with a different C++17 attribute was also observed in nlohmann/json#1535.
tanzislam added a commit to tanzislam/cryptopals that referenced this issue Oct 12, 2024
google/googletest@5a37b517ad introduced a check on `__has_cpp_attribute(maybe_unused)`. Under Clang it evaluates to true even in `-std=c++14` mode, but subsequently the use of the `[[maybe_unused]]` attribute triggers a `-Wc++17-extensions` warning which we elevate to an error via `-pedantic-errors`.

This was observed in Termux and in the macOS Travis CI environment, where we use Apple Clang: https://app.travis-ci.com/github/tanzislam/cryptopals/jobs/625697125

Interestingly, attempting to downgrade that error back to a warning with `-Wno-error=c++17-extensions` did not work.

A similar Clang issue with a different C++17 attribute was also observed in nlohmann/json#1535.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed kind: bug release item: 🔨 further change solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants