Clang should not warn about =delete("reason") in C++17 mode while claiming to support it

[dangelog]

Clang 19 seems to define __cpp_deleted_function even in pre-C++26 modes. However using it results in a warning:

void f() = delete
#if __cpp_deleted_function >= 202403L
    ("reason")
#endif
;

<source>:3:6: warning: '= delete' with a message is a C++2c extension [-Wc++26-extensions]
    3 |     ("reason")
      |      ^~~~~~~~
1 warning generated.
Compiler returned: 0

https://godbolt.org/z/Esqh5aPfb

It sounds a bit strange to claim support for a given language feature (by setting the corresponding feature-define macro), but then warn if that feature is used? Would it be possible, in pre-C++26 modes, to support the syntax and warn but not set the macro?

[frederick-vs-ja]

This is effectively a duplicate of #77262.

[shafik]

If your compiling w/ -std=c++17 the diagnostic is not saying that the compiler does not support it but that supporting it in C++17 mode is an extension.

[dangelog]

This is effectively a duplicate of #77262.

Indeed, it is. Feel free to close this one...

If your compiling w/ -std=c++17 the diagnostic is not saying that the compiler does not support it but that supporting it in C++17 mode is an extension.

Sure, but I'd still argue that in that case Clang must not set the feature-testing macro. This complicates life for code that wants to be compatible across multiple C++ versions: I can't do something as simple as:

#if __cpp_deleted_function >= 202403L
#define CPP_EQ_DELETE_X(reason) = delete(reason)
#else
#define CPP_EQ_DELETE_X(reason) = delete
#endif

void f() CPP_EQ_DELETE_X("whatever");

as this would trigger warnings when building in a pre-C++26 mode. I would instead need to guard it with the feature-testing macro and with a language version macro.

SD-6 says:

Implementers who provide a new standard feature should define a macro with the recommended name and value, in the same circumstances under which the feature is available (for example, taking into account relevant command-line options), to indicate the presence of support for that feature.

... but this doesn't fully clarify what "presence of support" means -- just that it's accepted by the implementation, even if it raises a diagnostic?

However, the following paragraph says:

Programmers who wish to determine whether a feature is available in an implementation should base that determination on the state of the macro with the recommended name.

And this confirms my reading: checking for the language version isn't required by the programmer, so Clang should either stop warning (undesirable) or stop advertising the feature.

[dangelog]

Also, =delete("reason") is meant to improve the quality of diagnostics, in case a user accidentally uses a deleted function. Having the feature available in earlier C++ language modes is therefore very valuable -- one gets better diagnostics, while at the same time staying in C++ < 26. Requiring C++26 (to avoid the "language extension" warning) kind of goes against the spirit of the feature, that is, wanting better diagnostics for the users.

[llvmbot]

@llvm/issue-subscribers-c-17

Author: Giuseppe D'Angelo (dangelog)

Clang 19 seems to define `__cpp_deleted_function` even in pre-C++26 modes. However using it results in a warning:

void f() = delete
#if __cpp_deleted_function >= 202403L
    ("reason")
#endif
;

<source>:3:6: warning: '= delete' with a message is a C++2c extension [-Wc++26-extensions]
    3 |     ("reason")
      |      ^~~~~~~~
1 warning generated.
Compiler returned: 0

https://godbolt.org/z/Esqh5aPfb

It sounds a bit strange to claim support for a given language feature (by setting the corresponding feature-define macro), but then warn if that feature is used? Would it be possible, in pre-C++26 modes, to support the syntax and warn but not set the macro?

[AaronBallman]

This seems like a case where we want to use Extension rather than ExtWarn for the diagnostic (

llvm-project/clang/include/clang/Basic/DiagnosticParseKinds.td

Line 974 in 5995e4b

def ext_delete_with_message : ExtWarn<

). Then it's a warning the user explicitly opts into, which makes more sense for a pure extension like this. I do not think a behavioral change is warranted regarding the feature test macro, that part of the issue is a duplicate of #77262.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.