[clang] Add `[[clang::library_extension]]` attribute

[philnik]

Summary

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

[cjdb]

clang/include/clang/Basic/DiagnosticSemaKinds.td

5690–5691

We shouldn't need this one, since Clang (almost) doesn't distinguish between C++03 and C++11. To my knowledge, C++03 doesn't even support attributes, so this would be a moot addition.

clang/lib/Sema/SemaDeclAttr.cpp

8227–8229

clang/test/SemaCXX/attr-library-extension.cpp

9–13

I don't think we need to test for both of these: using [[clang::library_extension]] directly should suffice.

[philnik]

clang/include/clang/Basic/DiagnosticSemaKinds.td

5690–5691

It does enough to regularly cause headaches (no >>, constexpr, alignas, buggy enum class). C++03 has supported GNU attributes forever, and since LLVM 17 also supports C++11 attributes. Also note that this isn't a new warning.

clang/test/SemaCXX/attr-library-extension.cpp

9–13

I've been asked to test both before, and IMO it's a good idea, since there are attributes which only have one of the spellings.

[ldionne]

I think I like this attribute.

However, I am concerned that this would make it seem more acceptable to add extensions to the library, when our policy has been that we don't (and for good reasons, we ran into big issues with e.g. std::string_view and we learned from those). Therefore, I would really support this (and obviously using it in libc++), but I would like us to write down (and justify) our policy about library extensions so that we can keep applying it firmly going forward. Then, I think it's a win-win situation for everyone. Users get diagnostics when they use extensions, libc++ gets a useful tool, and we don't start making bad decisions w.r.t. extensions that will bite us.

clang/include/clang/Basic/AttrDocs.td

1741

This should say clang::library_extension

1746

Perhaps the diagnostic should be std::string_view is a C++17 library extension?

1746–1747

[aaron.ballman]

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

Huh, so this is basically the opposite of the __extension__ macro (which is used to silence extension warnings)? I don't think we need to introduce a new attribute to do this, we already have diagnose_if. e.g., https://godbolt.org/z/a5ae4T56o would that suffice?

[philnik]

In D157572#4604482, @aaron.ballman wrote:

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

Huh, so this is basically the opposite of the __extension__ macro (which is used to silence extension warnings)?

I guess, kind-of. I never really understood the semantics of __extension__ though, so I'm not 100% certain.

I don't think we need to introduce a new attribute to do this, we already have diagnose_if. e.g., https://godbolt.org/z/a5ae4T56o would that suffice?

Part of the idea here is that the diagnostics should be part of -Wc++ab-extension. I guess we could allow warning flags instead of just "warning" and "error" in diagnose_if that specifies which warning group the diagnostic should be part of. Something like __attribute__((__diagnose_if__(__cplusplus >= 201703L, "basic_string_view is a C++17 extension", "-Wc++17-extensions"))). I'm not sure how one could implement that, but I guess there is some mechanism to translate "-Wwhatever" to a warning group, since you can push and pop warnings. That would open people up to add a diagnostic to pretty much any warning group. I don't know if that's a good idea. I don't really see a problem with that other than people writing weird code, but people do that all the time anyways. Maybe I'm missing something really problematic though.

[aaron.ballman]

In D157572#4604595, @philnik wrote:

In D157572#4604482, @aaron.ballman wrote:

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

Huh, so this is basically the opposite of the __extension__ macro (which is used to silence extension warnings)?

I guess, kind-of. I never really understood the semantics of __extension__ though, so I'm not 100% certain.

It's used in system headers to say "I'm using an extension here, don't warn about it in -pedantic mode".

I don't think we need to introduce a new attribute to do this, we already have diagnose_if. e.g., https://godbolt.org/z/a5ae4T56o would that suffice?

Part of the idea here is that the diagnostics should be part of -Wc++ab-extension.

Hmmm, okay. And I'm assuming -Wsystem-headers -pedantic is too chatty because it's telling the user about all use of extensions, not extensions being introduced by the library itself? (e.g., https://godbolt.org/z/Gs3YGheMM is also not what you're after)

I guess we could allow warning flags instead of just "warning" and "error" in diagnose_if that specifies which warning group the diagnostic should be part of. Something like __attribute__((__diagnose_if__(__cplusplus >= 201703L, "basic_string_view is a C++17 extension", "-Wc++17-extensions"))). I'm not sure how one could implement that, but I guess there is some mechanism to translate "-Wwhatever" to a warning group, since you can push and pop warnings. That would open people up to add a diagnostic to pretty much any warning group. I don't know if that's a good idea. I don't really see a problem with that other than people writing weird code, but people do that all the time anyways. Maybe I'm missing something really problematic though.

That's actually a pretty interesting idea; diagnose_if could be given another parameter to specify a diagnostic group to associate the diagnostic with. This would let you do some really handy things like:

void func(int i) __attribute__((diagnose_if(i < 0, "passing a negative value to 'func' is deprecated", "warning", "-Wdeprecated")));

But if we went this route, would we want to expose other diagnostic-related knobs like "show in system header" and "default to an error"? Also, the attribute currently can only be associated with a function; we can use this for classes by sticking it on a constructor but there's not much help for putting it on say a namespace or an enumeration. So we may need to extend the attribute in other ways. CC @cjdb as this seems of interest to you as well.

[philnik]

In D157572#4606513, @aaron.ballman wrote:

In D157572#4604595, @philnik wrote:

In D157572#4604482, @aaron.ballman wrote:

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

Huh, so this is basically the opposite of the __extension__ macro (which is used to silence extension warnings)?

I guess, kind-of. I never really understood the semantics of __extension__ though, so I'm not 100% certain.

It's used in system headers to say "I'm using an extension here, don't warn about it in -pedantic mode".

Hm, OK. I thought I tried to use it that way at some point and it didn't work in the way I expected.

I don't think we need to introduce a new attribute to do this, we already have diagnose_if. e.g., https://godbolt.org/z/a5ae4T56o would that suffice?

Part of the idea here is that the diagnostics should be part of -Wc++ab-extension.

Hmmm, okay. And I'm assuming -Wsystem-headers -pedantic is too chatty because it's telling the user about all use of extensions, not extensions being introduced by the library itself? (e.g., https://godbolt.org/z/Gs3YGheMM is also not what you're after)

Yeah, for libc++ we don't support -Wsystem-headers in any meaningful way and this doesn't achieve the effect I want.

I guess we could allow warning flags instead of just "warning" and "error" in diagnose_if that specifies which warning group the diagnostic should be part of. Something like __attribute__((__diagnose_if__(__cplusplus >= 201703L, "basic_string_view is a C++17 extension", "-Wc++17-extensions"))). I'm not sure how one could implement that, but I guess there is some mechanism to translate "-Wwhatever" to a warning group, since you can push and pop warnings. That would open people up to add a diagnostic to pretty much any warning group. I don't know if that's a good idea. I don't really see a problem with that other than people writing weird code, but people do that all the time anyways. Maybe I'm missing something really problematic though.

That's actually a pretty interesting idea; diagnose_if could be given another parameter to specify a diagnostic group to associate the diagnostic with. This would let you do some really handy things like:

void func(int i) __attribute__((diagnose_if(i < 0, "passing a negative value to 'func' is deprecated", "warning", "-Wdeprecated")));

But if we went this route, would we want to expose other diagnostic-related knobs like "show in system header" and "default to an error"? Also, the attribute currently can only be associated with a function; we can use this for classes by sticking it on a constructor but there's not much help for putting it on say a namespace or an enumeration. So we may need to extend the attribute in other ways. CC @cjdb as this seems of interest to you as well.

I looked a bit around the code yesterday and it looks like it should be relatively easy to implement. I think we would just have to extend CustomDiagInfo to save some more information and pass the warning group in there from the diagnose_if sema handler. There are already utilities to translate -Wwhatever into the corresponding warning group IDs, so that part is trivial. Given that, I think this sounds like a very interesting way to go. This would also allow us to move the libc++ atomic checks to -Watomic-memory-ordering and I'm sure there will be more use-cases. Regarding the knobs, I think that would be interesting for some things too. We could add optional string arguments at the end like "show_in_system_header={false,true}", "default_to_error={false,true}", "enable_by_default={false,true}", etc. If they aren't set we probably want to default to show_in_system_header=false, default_to_error=false and enable_by_default=true. Are there any other interesting knobs?

[cjdb]

In D157572#4606513, @aaron.ballman wrote:

In D157572#4604595, @philnik wrote:

In D157572#4604482, @aaron.ballman wrote:

This allows standard libraries to mark symbols as extensions, so the compiler can generate extension warnings when they are used.

Huh, so this is basically the opposite of the __extension__ macro (which is used to silence extension warnings)?

I guess, kind-of. I never really understood the semantics of __extension__ though, so I'm not 100% certain.

It's used in system headers to say "I'm using an extension here, don't warn about it in -pedantic mode".

I don't think we need to introduce a new attribute to do this, we already have diagnose_if. e.g., https://godbolt.org/z/a5ae4T56o would that suffice?

Part of the idea here is that the diagnostics should be part of -Wc++ab-extension.

Hmmm, okay. And I'm assuming -Wsystem-headers -pedantic is too chatty because it's telling the user about all use of extensions, not extensions being introduced by the library itself? (e.g., https://godbolt.org/z/Gs3YGheMM is also not what you're after)

I guess we could allow warning flags instead of just "warning" and "error" in diagnose_if that specifies which warning group the diagnostic should be part of. Something like __attribute__((__diagnose_if__(__cplusplus >= 201703L, "basic_string_view is a C++17 extension", "-Wc++17-extensions"))). I'm not sure how one could implement that, but I guess there is some mechanism to translate "-Wwhatever" to a warning group, since you can push and pop warnings. That would open people up to add a diagnostic to pretty much any warning group. I don't know if that's a good idea. I don't really see a problem with that other than people writing weird code, but people do that all the time anyways. Maybe I'm missing something really problematic though.

That's actually a pretty interesting idea; diagnose_if could be given another parameter to specify a diagnostic group to associate the diagnostic with. This would let you do some really handy things like:

void func(int i) __attribute__((diagnose_if(i < 0, "passing a negative value to 'func' is deprecated", "warning", "-Wdeprecated")));

But if we went this route, would we want to expose other diagnostic-related knobs like "show in system header" and "default to an error"? Also, the attribute currently can only be associated with a function; we can use this for classes by sticking it on a constructor but there's not much help for putting it on say a namespace or an enumeration. So we may need to extend the attribute in other ways. CC @cjdb as this seems of interest to you as well.

I don't dislike it, but I am a bit concerned about misuse being noisy. As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

[aaron.ballman]

In D157572#4612141, @cjdb wrote:

I don't dislike it, but I am a bit concerned about misuse being noisy.

So you're concerned that a library author uses diagnose_if to add a diagnostic to a warning group that makes the diagnostic seem too chatty, so the user disables the group and loses the compiler's diagnostics? Or are there other kinds of misuse you're worried about?

As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

Correct, those will still show up when the declaration is in a system header but not when the use is in a system header: https://godbolt.org/z/PjqKbGsrr

We currently have -Wuser-defined-warnings as the warning group for diagnose_if warning diagnostics, so I wonder if it would make sense to allow -Wno-deprecated suppresses anything that -Wdeprecated would turn on, while -Wdeprecated -Wno-user-defined-warnings would turn on only the compiler-generated deprecation warnings and not the diagnose_if-generated ones?

[cjdb]

In D157572#4613622, @aaron.ballman wrote:

In D157572#4612141, @cjdb wrote:

I don't dislike it, but I am a bit concerned about misuse being noisy.

So you're concerned that a library author uses diagnose_if to add a diagnostic to a warning group that makes the diagnostic seem too chatty, so the user disables the group and loses the compiler's diagnostics? Or are there other kinds of misuse you're worried about?

More or less the former. I don't know if it'll actually manifest in practice though, I don't see many diagnose_if diagnostics to begin with.

As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

Correct, those will still show up when the declaration is in a system header but not when the use is in a system header: https://godbolt.org/z/PjqKbGsrr

Right, my question was more "what is this knob doing?"

We currently have -Wuser-defined-warnings as the warning group for diagnose_if warning diagnostics, so I wonder if it would make sense to allow -Wno-deprecated suppresses anything that -Wdeprecated would turn on, while -Wdeprecated -Wno-user-defined-warnings would turn on only the compiler-generated deprecation warnings and not the diagnose_if-generated ones?

Oh neat, this simplifies things a lot!

[aaron.ballman]

In D157572#4614561, @cjdb wrote:

In D157572#4613622, @aaron.ballman wrote:

In D157572#4612141, @cjdb wrote:

I don't dislike it, but I am a bit concerned about misuse being noisy.

So you're concerned that a library author uses diagnose_if to add a diagnostic to a warning group that makes the diagnostic seem too chatty, so the user disables the group and loses the compiler's diagnostics? Or are there other kinds of misuse you're worried about?

More or less the former. I don't know if it'll actually manifest in practice though, I don't see many diagnose_if diagnostics to begin with.

I think the former is sort of a "doctor, doctor, it hurts" situation; the issue isn't really with diagnose_if, it's with the library author's use of it. But at the same time, I can see why it would be beneficial to be able to work around it if needed.

As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

Correct, those will still show up when the declaration is in a system header but not when the use is in a system header: https://godbolt.org/z/PjqKbGsrr

Right, my question was more "what is this knob doing?"

Ah! We have various knobs on our diagnostics, like:
ShowInSystemHeader -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L7818 (if used, the diagnostic will be shown in a system header)
SFINAEFailure -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L93 (if used, the diagnostic causes SFINAE to fail in a SFINAE context)
DefaultIgnore -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L141 (if used, the warning is off by default and must be explicitly enabled via its group)
DefaultError -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L262 (if used, the warning defaults to being an error but users can disable the error with -Wno)
(etc)

All of these have been of use to us as implementers, so it seems likely that these same knobs would be of use to library authors adding their own compiler diagnostics, so perhaps we should consider that as part of the design?

We currently have -Wuser-defined-warnings as the warning group for diagnose_if warning diagnostics, so I wonder if it would make sense to allow -Wno-deprecated suppresses anything that -Wdeprecated would turn on, while -Wdeprecated -Wno-user-defined-warnings would turn on only the compiler-generated deprecation warnings and not the diagnose_if-generated ones?

Oh neat, this simplifies things a lot!

I think it could make for a reasonable user experience.

I'm curious what @erichkeane thinks as attributes code owner, but personally, I like the idea of extending diagnose_if over the idea of adding clang::library_extension because it's a more general solution that I think will give more utility to our users. However, I also want to know if @philnik @Mordante @ldionne (and others) share that preference because I think they're going to be the guinea pigs^W^Wearly adopters of this functionality.

[philnik]

In D157572#4617504, @aaron.ballman wrote:

In D157572#4614561, @cjdb wrote:

In D157572#4613622, @aaron.ballman wrote:

In D157572#4612141, @cjdb wrote:

I don't dislike it, but I am a bit concerned about misuse being noisy.

So you're concerned that a library author uses diagnose_if to add a diagnostic to a warning group that makes the diagnostic seem too chatty, so the user disables the group and loses the compiler's diagnostics? Or are there other kinds of misuse you're worried about?

More or less the former. I don't know if it'll actually manifest in practice though, I don't see many diagnose_if diagnostics to begin with.

I think the former is sort of a "doctor, doctor, it hurts" situation; the issue isn't really with diagnose_if, it's with the library author's use of it. But at the same time, I can see why it would be beneficial to be able to work around it if needed.

As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

Correct, those will still show up when the declaration is in a system header but not when the use is in a system header: https://godbolt.org/z/PjqKbGsrr

Right, my question was more "what is this knob doing?"

Ah! We have various knobs on our diagnostics, like:
ShowInSystemHeader -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L7818 (if used, the diagnostic will be shown in a system header)
SFINAEFailure -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L93 (if used, the diagnostic causes SFINAE to fail in a SFINAE context)
DefaultIgnore -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L141 (if used, the warning is off by default and must be explicitly enabled via its group)
DefaultError -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L262 (if used, the warning defaults to being an error but users can disable the error with -Wno)
(etc)

All of these have been of use to us as implementers, so it seems likely that these same knobs would be of use to library authors adding their own compiler diagnostics, so perhaps we should consider that as part of the design?

We currently have -Wuser-defined-warnings as the warning group for diagnose_if warning diagnostics, so I wonder if it would make sense to allow -Wno-deprecated suppresses anything that -Wdeprecated would turn on, while -Wdeprecated -Wno-user-defined-warnings would turn on only the compiler-generated deprecation warnings and not the diagnose_if-generated ones?

Oh neat, this simplifies things a lot!

I think it could make for a reasonable user experience.

I'm curious what @erichkeane thinks as attributes code owner, but personally, I like the idea of extending diagnose_if over the idea of adding clang::library_extension because it's a more general solution that I think will give more utility to our users. However, I also want to know if @philnik @Mordante @ldionne (and others) share that preference because I think they're going to be the guinea pigs^W^Wearly adopters of this functionality.

I think this approach makes a lot of sense. I'm not sure all the knobs make sense to expose (e.g. SFINAEFailure could just be implemented with a normal enable_if IIUC), but at least ShowInSystemHeader and DefaultIgnore are ones where I already have use-cases in mind. As said before, we could also move our atomic ordering warnings from -Wuser-defined-warnings to -Watomic-memory-ordering, which seems like a huge usability improvement. I'm sure there will be more use-cases in the future for extending warning flags and having the ability to tune how and when warnings are emitted.

[cjdb]

In D157572#4617504, @aaron.ballman wrote:

In D157572#4614561, @cjdb wrote:

In D157572#4613622, @aaron.ballman wrote:

In D157572#4612141, @cjdb wrote:

I don't dislike it, but I am a bit concerned about misuse being noisy.

So you're concerned that a library author uses diagnose_if to add a diagnostic to a warning group that makes the diagnostic seem too chatty, so the user disables the group and loses the compiler's diagnostics? Or are there other kinds of misuse you're worried about?

More or less the former. I don't know if it'll actually manifest in practice though, I don't see many diagnose_if diagnostics to begin with.

I think the former is sort of a "doctor, doctor, it hurts" situation; the issue isn't really with diagnose_if, it's with the library author's use of it. But at the same time, I can see why it would be beneficial to be able to work around it if needed.

As much as I hate suppressing diagnostics, I think there needs to be a way to suppress the diagnose_if forms of warning without suppressing something that the compiler would otherwise generate. Something like:

• -Wno-deprecated: suppresses anything that -Wdeprecated would turn on.
• -Wno-deprecated=diagnose_if: just the ones flagged by diagnose_if.
• -Wno-deprecated=non-diagnose_if: complement to #2.

(and similarly for -Wno-error=.)

I'm not sure about the system header knob though: [[deprecated]] and [[nodiscard]] still show up even when the declaration is in a system header?

Correct, those will still show up when the declaration is in a system header but not when the use is in a system header: https://godbolt.org/z/PjqKbGsrr

Right, my question was more "what is this knob doing?"

Ah! We have various knobs on our diagnostics, like:
ShowInSystemHeader -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L7818 (if used, the diagnostic will be shown in a system header)
SFINAEFailure -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L93 (if used, the diagnostic causes SFINAE to fail in a SFINAE context)
DefaultIgnore -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L141 (if used, the warning is off by default and must be explicitly enabled via its group)
DefaultError -- https://github.com/llvm/llvm-project/blob/2dc6281b98d07f43a64d0ef34405d9a12d59e8b6/clang/include/clang/Basic/DiagnosticSemaKinds.td#L262 (if used, the warning defaults to being an error but users can disable the error with -Wno)
(etc)

All of these have been of use to us as implementers, so it seems likely that these same knobs would be of use to library authors adding their own compiler diagnostics, so perhaps we should consider that as part of the design?

We currently have -Wuser-defined-warnings as the warning group for diagnose_if warning diagnostics, so I wonder if it would make sense to allow -Wno-deprecated suppresses anything that -Wdeprecated would turn on, while -Wdeprecated -Wno-user-defined-warnings would turn on only the compiler-generated deprecation warnings and not the diagnose_if-generated ones?

Oh neat, this simplifies things a lot!

I think it could make for a reasonable user experience.

I'm curious what @erichkeane thinks as attributes code owner, but personally, I like the idea of extending diagnose_if over the idea of adding clang::library_extension because it's a more general solution that I think will give more utility to our users. However, I also want to know if @philnik @Mordante @ldionne (and others) share that preference because I think they're going to be the guinea pigs^W^Wearly adopters of this functionality.

I like this idea, but we need to acknowledge that it'll potentially lead to diagnostics with varying quality. This conversation may be better suited to a Discourse thread at this point: there seems to be a lot of design before we reach consensus, and a CL isn't the optimal place to do that.

[cjdb]

Started a thread: https://discourse.llvm.org/t/exposing-the-diagnostic-engine-to-c/73092

[philnik]

Abandoning, since it seems like we want to extend diagnose_if instead.

clang/include/clang/AST/DeclBase.h

 class TranslationUnitDecl;
 class UsingDirectiveDecl;
 
 /// Captures the result of checking the availability of a
 /// declaration.
 enum AvailabilityResult {
   AR_Available = 0,
   AR_NotYetIntroduced,
+  AR_Extension,
   AR_Deprecated,
-  AR_Unavailable
+  AR_Unavailable,
 };
 
 /// Decl - This represents one declaration (or definition), e.g. a variable,
 /// typedef, function, struct, etc.
 ///
 /// Note: There are objects tacked on before the *beginning* of Decl
 /// (and its subclasses) in its Decl::operator new(). Proper alignment
 /// of all subclasses (not requiring more than the alignment of Decl) is

clang/include/clang/Basic/Attr.td

return llvm::StringSwitch<llvm::StringRef>(Platform)
              .Default(Platform);
 } }];
   let HasCustomParsing = 1;
   let InheritEvenIfAlreadyPresent = 1;
   let Subjects = SubjectList<[Named]>;
   let Documentation = [AvailabilityDocs];
 }
 
+def LibraryExtension : InheritableAttr {
+  let Spellings = [Clang<"library_extension", /*allowInC=*/0>];
+  let Args = [StringArgument<"kind">];
+  let Subjects = SubjectList<[Named]>;
+  let Documentation = [ExtensionDocs];
+  let MeaningfulToClassTemplateDefinition = 1;
+}
+
 def ExternalSourceSymbol : InheritableAttr {
   let Spellings = [Clang<"external_source_symbol", /*allowInC=*/1,
                    /*version=*/20230206>];
   let Args = [StringArgument<"language", 1>,
               StringArgument<"definedIn", 1>,
               BoolArgument<"generatedDeclaration", 1>,
               StringArgument<"USR", 1>];
   let HasCustomParsing = 1;
def ReadOnlyPlacement : InheritableAttr {
   let Documentation = [ReadOnlyPlacementDocs];
 }
 
 def AvailableOnlyInDefaultEvalMethod : InheritableAttr {
   let Spellings = [Clang<"available_only_in_default_eval_method">];
   let Subjects = SubjectList<[TypedefName], ErrorDiag>;
   let Documentation = [Undocumented];
 }
-

clang/include/clang/Basic/AttrDocs.td

void infersTVOSAvailabilityFromAttributeNextToDeclaration(void)
     __attribute__((availability(iOS,introduced=11.0)));
   #pragma clang attribute pop
 
 Also see the documentation for `@available
 <http://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available>`_
   }];
 }
 
+def ExtensionDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``clang::extension`` attribute tells the compiler that the annotated symbol
+is an extension. This is useful for standard library implementations to inform
+users that a given symbol is from a later standard or completely non-standard.
+
+.. code-block:: c++
+
+  namespace std {
+    template <class CharT, class Traits = char_traits<CharT>>
+    class [[clang::extension("C++17")]] basic_string_view { /*...*/ };
+
+    using string_view = basic_string_view<char>;
+  }
+
+  // Clang produces the warning "std::string_view is a C++17 extension"
+  void func(std::string_view);
+
+The currently supported argument arguments are "C++11", "C++14", "C++17", "C++20",
+"C++23", "C++26" and "GNU".
+  }];
+}
+
 def ExternalSourceSymbolDocs : Documentation {
   let Category = DocCatDecl;
   let Content = [{
 The ``external_source_symbol`` attribute specifies that a declaration originates
 from an external source and describes the nature of that source.
 
 The fact that Clang is capable of recognizing declarations that were defined
 externally can be used to provide better tooling support for mixed-language

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def err_property_method_unavailable :
     Error<"property access is using %0 method which is unavailable">;
 def err_unavailable_message : Error<"%0 is unavailable: %1">;
 def warn_unavailable_fwdclass_message : Warning<
     "%0 may be unavailable because the receiver type is unknown">,
     InGroup<UnavailableDeclarations>;
 def note_availability_specified_here : Note<
   "%0 has been explicitly marked "
-  "%select{unavailable|deleted|deprecated}1 here">;
+  "%select{unavailable|deleted|deprecated|as an extension}1 here">;
 def note_partial_availability_specified_here : Note<
   "%0 has been marked as being introduced in %1 %2 here, "
   "but the deployment target is %1 %3">;
+def warn_unknown_ext : Warning<"Unknown extension kind: %0">;
+def warn_cxx11_ext : Warning<"%0 is a C++11 extension">,
+    InGroup<CXX11>;
+def warn_cxx14_ext : Warning<"%0 is a C++14 extension">,
+    InGroup<CXX14>;
+def warn_cxx17_ext : Warning<"%0 is a C++17 extension">,
+    InGroup<CXX17>;
+def warn_cxx20_ext : Warning<"%0 is a C++20 extension">,
+    InGroup<CXX20>;
+def warn_cxx23_ext : Warning<"%0 is a C++23 extension">,
+    InGroup<CXX23>;
+def warn_cxx26_ext : Warning<"%0 is a C++2c extension">,
+    InGroup<CXX26>;
+def warn_gnu_ext : Warning<"%0 is a GNU extension">,
+    InGroup<GNU>;
 def note_implicitly_deleted : Note<
   "explicitly defaulted function was implicitly deleted here">;
 def warn_not_enough_argument : Warning<
   "not enough variable arguments in %0 declaration to fit a sentinel">,
   InGroup<Sentinel>;
 def warn_missing_sentinel : Warning <
   "missing sentinel in %select{function call|method dispatch|block call}0">,
   InGroup<Sentinel>;

clang/lib/AST/DeclBase.cpp

if (const auto *Deprecated = dyn_cast<DeprecatedAttr>(A)) {
 
       if (Message)
         ResultMessage = std::string(Deprecated->getMessage());
 
       Result = AR_Deprecated;
       continue;
     }
 
+    if (const auto* Extension = dyn_cast<LibraryExtensionAttr>(A)) {
+      if (Result >= AR_Extension)
+        continue;
+
+      auto ExtKind = Extension->getKind();
+      if ((!getLangOpts().CPlusPlus26 && ExtKind == "C++26") ||
+          (!getLangOpts().CPlusPlus23 && ExtKind == "C++23") ||
+          (!getLangOpts().CPlusPlus20 && ExtKind == "C++20") ||
+          (!getLangOpts().CPlusPlus17 && ExtKind == "C++17") ||
+          (!getLangOpts().CPlusPlus14 && ExtKind == "C++14") ||
+          (!getLangOpts().CPlusPlus11 && ExtKind == "C++11") ||
+          ExtKind == "GNU")
+        Result = AR_Extension;
+      continue;
+    }
+
     if (const auto *Unavailable = dyn_cast<UnavailableAttr>(A)) {
       if (Message)
         *Message = std::string(Unavailable->getMessage());
       return AR_Unavailable;
     }
 
     if (const auto *Availability = dyn_cast<AvailabilityAttr>(A)) {
       AvailabilityResult AR = CheckAvailability(getASTContext(), Availability,

clang/lib/Sema/CodeCompleteConsumer.cpp

case RK_Pattern:
     }
     [[fallthrough]];
 
   case RK_Declaration: {
     // Set the availability based on attributes.
     switch (getDeclAvailability(Declaration)) {
     case AR_Available:
     case AR_NotYetIntroduced:
+    case AR_Extension:
       Availability = CXAvailability_Available;
       break;
 
     case AR_Deprecated:
       Availability = CXAvailability_Deprecated;
       break;
 
     case AR_Unavailable:

clang/lib/Sema/SemaAvailability.cpp

if (const auto *Enclosing = findEnclosingDeclToAnnotate(Ctx)) {
       FixitNoteDiag << FixItHint::CreateInsertion(
           Insertion->Loc,
           (llvm::Twine(Insertion->Prefix) + "API_AVAILABLE(" + PlatformName +
            "(" + Introduced + "))" + Insertion->Suffix)
               .str());
     }
     return;
   }
+  case AR_Extension: {
+    assert(Message.empty());
+    auto ExtKind = OffendingDecl->getAttr<LibraryExtensionAttr>()->getKind();
+    if (ExtKind == "C++11")
+      diag = diag::warn_cxx11_ext;
+    else if (ExtKind == "C++14")
+      diag = diag::warn_cxx14_ext;
+    else if (ExtKind == "C++17")
+      diag = diag::warn_cxx17_ext;
+    else if (ExtKind == "C++20")
+      diag = diag::warn_cxx20_ext;
+    else if (ExtKind == "C++23")
+      diag = diag::warn_cxx23_ext;
+    else if (ExtKind == "C++26")
+      diag = diag::warn_cxx26_ext;
+    else if (ExtKind == "GNU")
+      diag = diag::warn_gnu_ext;
+
+    available_here_select_kind = 3;
+    if (const auto *AL = OffendingDecl->getAttr<LibraryExtensionAttr>())
+      NoteLocation = AL->getLocation();
+
+    break;
+  }
+
   case AR_Deprecated:
     diag = !ObjCPropertyAccess ? diag::warn_deprecated
                                : diag::warn_property_method_deprecated;
     diag_message = diag::warn_deprecated_message;
     diag_fwdclass_message = diag::warn_deprecated_fwdclass_message;
     property_note_select = /* deprecated */ 0;
     available_here_select_kind = /* deprecated */ 2;
     if (const auto *AL = OffendingDecl->getAttr<DeprecatedAttr>())

clang/lib/Sema/SemaDeclAttr.cpp

else if (AL.isArgExpr(1) && AL.getArgAsExpr(1) &&
     return;
 
   if (!S.getLangOpts().CPlusPlus14 && AL.isCXX11Attribute() && !AL.isGNUScope())
     S.Diag(AL.getLoc(), diag::ext_cxx14_attr) << AL;
 
   D->addAttr(::new (S.Context) DeprecatedAttr(S.Context, AL, Str, Replacement));
 }
 
+static void handleLibraryExtensionAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  StringRef Kind;
+  if (!S.checkStringLiteralArgumentAttr(AL, 0, Kind))
+    return;
+  if (llvm::none_of(std::array{"C++11", "C++14", "C++17", "C++20", "C++23",
+                               "C++26", "GNU"},
+                    [&](const char *K) { return K == Kind; })) {
+    S.Diag(AL.getLoc(), diag::warn_unknown_ext) << Kind;
+  }
+
+    D->addAttr(::new (S.Context) LibraryExtensionAttr(S.Context, AL, Kind));
+}
+
 static bool isGlobalVar(const Decl *D) {
   if (const auto *S = dyn_cast<VarDecl>(D))
     return S->hasGlobalStorage();
   return false;
 }
 
 static bool isSanitizerAttributeAllowedOnGlobals(StringRef Sanitizer) {
   return Sanitizer == "address" || Sanitizer == "hwaddress" ||
case ParsedAttr::AT_Destructor:
       handleDestructorAttr(S, D, AL);
     break;
   case ParsedAttr::AT_EnableIf:
     handleEnableIfAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Error:
     handleErrorAttr(S, D, AL);
     break;
+  case ParsedAttr::AT_LibraryExtension:
+    handleLibraryExtensionAttr(S, D, AL);
+    break;
   case ParsedAttr::AT_DiagnoseIf:
     handleDiagnoseIfAttr(S, D, AL);
     break;
   case ParsedAttr::AT_DiagnoseAsBuiltin:
     handleDiagnoseAsBuiltinAttr(S, D, AL);
     break;
   case ParsedAttr::AT_NoBuiltin:
     handleNoBuiltinAttr(S, D, AL);

clang/lib/Sema/SemaStmt.cpp

if (!CaseListIsErroneous && !CaseListIsIncomplete && !HasConstantCond &&
       SmallVector<DeclarationName,8> UnhandledNames;
 
       for (EI = EnumVals.begin(); EI != EIEnd; EI++) {
         // Don't warn about omitted unavailable EnumConstantDecls.
         switch (EI->second->getAvailability()) {
         case AR_Deprecated:
           // Omitting a deprecated constant is ok; it should never materialize.
         case AR_Unavailable:
+        case AR_Extension:
           continue;
 
         case AR_NotYetIntroduced:
           // Partially available enum constants should be present. Note that we
           // suppress -Wunguarded-availability diagnostics for such uses.
         case AR_Available:
           break;
         }

clang/test/SemaCXX/attr-library-extension.cpp

+// RUN: %clang_cc1 -Wno-unused-value -std=c++03 -verify=cxx03,cxx11,cxx14,cxx17,cxx20,cxx23,gnu -fsyntax-only %s -DGNUAttr
+// RUN: %clang_cc1 -Wno-unused-value -std=c++11 -verify=cxx11,cxx14,cxx17,cxx20,cxx23,gnu -fsyntax-only %s
+// RUN: %clang_cc1 -Wno-unused-value -std=c++14 -verify=cxx14,cxx17,cxx20,cxx23,gnu -fsyntax-only %s
+// RUN: %clang_cc1 -Wno-unused-value -std=c++17 -verify=cxx17,cxx20,cxx23,gnu -fsyntax-only %s
+// RUN: %clang_cc1 -Wno-unused-value -std=c++20 -verify=cxx20,cxx23,gnu -fsyntax-only %s
+// RUN: %clang_cc1 -Wno-unused-value -std=c++23 -verify=cxx23,gnu -fsyntax-only %s
+// RUN: %clang_cc1 -Wno-unused-value -std=c++26 -verify=gnu -fsyntax-only %s
+
+#ifdef GNUAttr
+#define EXTENSION(name) __attribute__((library_extension(name)))
+#else
+#define EXTENSION(name) [[clang::library_extension(name)]]
+#endif
+
+struct EXTENSION("C++11") StructCxx11Ext {}; // cxx03-note {{'StructCxx11Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("C++14") StructCxx14Ext {}; // cxx11-note {{'StructCxx14Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("C++17") StructCxx17Ext {}; // cxx14-note {{'StructCxx17Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("C++20") StructCxx20Ext {}; // cxx17-note {{'StructCxx20Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("C++23") StructCxx23Ext {}; // cxx20-note {{'StructCxx23Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("C++26") StructCxx26Ext {}; // cxx23-note {{'StructCxx26Ext' has been explicitly marked as an extension here}}
+struct EXTENSION("GNU") GNUExt {}; // gnu-note {{'GNUExt' has been explicitly marked as an extension here}}
+
+void consume(StructCxx11Ext); // cxx03-warning {{'StructCxx11Ext' is a C++11 extension}}
+void consume(StructCxx14Ext); // cxx11-warning {{'StructCxx14Ext' is a C++14 extension}}
+void consume(StructCxx17Ext); // cxx14-warning {{'StructCxx17Ext' is a C++17 extension}}
+void consume(StructCxx20Ext); // cxx17-warning {{'StructCxx20Ext' is a C++20 extension}}
+void consume(StructCxx23Ext); // cxx20-warning {{'StructCxx23Ext' is a C++23 extension}}
+void consume(StructCxx26Ext); // cxx23-warning {{'StructCxx26Ext' is a C++2c extension}}
+void consume(GNUExt); // gnu-warning {{'GNUExt' is a GNU extension}}
+
+namespace EXTENSION("C++11") NSCxx11Ext { // cxx03-note {{'NSCxx11Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx11Ext::S); // cxx03-warning {{'NSCxx11Ext' is a C++11 extension}}
+
+namespace EXTENSION("C++14") NSCxx14Ext { // cxx11-note {{'NSCxx14Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx14Ext::S); // cxx11-warning {{'NSCxx14Ext' is a C++14 extension}}
+
+namespace EXTENSION("C++17") NSCxx17Ext { // cxx14-note {{'NSCxx17Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx17Ext::S); // cxx14-warning {{'NSCxx17Ext' is a C++17 extension}}
+
+namespace EXTENSION("C++20") NSCxx20Ext { // cxx17-note {{'NSCxx20Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx20Ext::S); // cxx17-warning {{'NSCxx20Ext' is a C++20 extension}}
+
+namespace EXTENSION("C++23") NSCxx23Ext { // cxx20-note {{'NSCxx23Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx23Ext::S); // cxx20-warning {{'NSCxx23Ext' is a C++23 extension}}
+
+namespace EXTENSION("C++26") NSCxx26Ext { // cxx23-note {{'NSCxx26Ext' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSCxx26Ext::S); // cxx23-warning {{'NSCxx26Ext' is a C++2c extension}}
+
+namespace EXTENSION("GNU") NSGNUExt { // gnu-note {{'NSGNUExt' has been explicitly marked as an extension here}}
+  struct S {};
+}
+void consume(NSGNUExt::S); // gnu-warning {{'NSGNUExt' is a GNU extension}}
+
+EXTENSION("C++11") void fcxx11(); // cxx03-note {{'fcxx11' has been explicitly marked as an extension here}}
+EXTENSION("C++14") void fcxx14(); // cxx11-note {{'fcxx14' has been explicitly marked as an extension here}}
+EXTENSION("C++17") void fcxx17(); // cxx14-note {{'fcxx17' has been explicitly marked as an extension here}}
+EXTENSION("C++20") void fcxx20(); // cxx17-note {{'fcxx20' has been explicitly marked as an extension here}}
+EXTENSION("C++23") void fcxx23(); // cxx20-note {{'fcxx23' has been explicitly marked as an extension here}}
+EXTENSION("C++26") void fcxx26(); // cxx23-note {{'fcxx26' has been explicitly marked as an extension here}}
+EXTENSION("GNU") void fgnu(); // gnu-note {{'fgnu' has been explicitly marked as an extension here}}
+
+void call() {
+  fcxx11(); // cxx03-warning {{'fcxx11' is a C++11 extension}}
+  fcxx14(); // cxx11-warning {{'fcxx14' is a C++14 extension}}
+  fcxx17(); // cxx14-warning {{'fcxx17' is a C++17 extension}}
+  fcxx20(); // cxx17-warning {{'fcxx20' is a C++20 extension}}
+  fcxx23(); // cxx20-warning {{'fcxx23' is a C++23 extension}}
+  fcxx26(); // cxx23-warning {{'fcxx26' is a C++2c extension}}
+  fgnu(); // gnu-warning {{'fgnu' is a GNU extension}}
+}
+
+EXTENSION("C++11") int vcxx11; // cxx03-note {{'vcxx11' has been explicitly marked as an extension here}}
+EXTENSION("C++14") int vcxx14; // cxx11-note {{'vcxx14' has been explicitly marked as an extension here}}
+EXTENSION("C++17") int vcxx17; // cxx14-note {{'vcxx17' has been explicitly marked as an extension here}}
+EXTENSION("C++20") int vcxx20; // cxx17-note {{'vcxx20' has been explicitly marked as an extension here}}
+EXTENSION("C++23") int vcxx23; // cxx20-note {{'vcxx23' has been explicitly marked as an extension here}}
+EXTENSION("C++26") int vcxx26; // cxx23-note {{'vcxx26' has been explicitly marked as an extension here}}
+EXTENSION("GNU") int vgnu; // gnu-note {{'vgnu' has been explicitly marked as an extension here}}
+
+void access() {
+  vcxx11; // cxx03-warning {{'vcxx11' is a C++11 extension}}
+  vcxx14; // cxx11-warning {{'vcxx14' is a C++14 extension}}
+  vcxx17; // cxx14-warning {{'vcxx17' is a C++17 extension}}
+  vcxx20; // cxx17-warning {{'vcxx20' is a C++20 extension}}
+  vcxx23; // cxx20-warning {{'vcxx23' is a C++23 extension}}
+  vcxx26; // cxx23-warning {{'vcxx26' is a C++2c extension}}
+  vgnu; // gnu-warning {{'vgnu' is a GNU extension}}
+}
+
+template <class>
+class EXTENSION("C++11") TemplateCxx11Ext {}; // cxx03-note {{'TemplateCxx11Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx11Ext<void>); // cxx03-warning {{'TemplateCxx11Ext<void>' is a C++11 extension}}
+
+template <class>
+class EXTENSION("C++14") TemplateCxx14Ext {}; // cxx11-note {{'TemplateCxx14Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx14Ext<void>); // cxx11-warning {{'TemplateCxx14Ext<void>' is a C++14 extension}}
+
+template <class>
+class EXTENSION("C++17") TemplateCxx17Ext {}; // cxx14-note {{'TemplateCxx17Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx17Ext<void>); // cxx14-warning {{'TemplateCxx17Ext<void>' is a C++17 extension}}
+
+template <class>
+class EXTENSION("C++20") TemplateCxx20Ext {}; // cxx17-note {{'TemplateCxx20Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx20Ext<void>); // cxx17-warning {{'TemplateCxx20Ext<void>' is a C++20 extension}}
+
+template <class>
+class EXTENSION("C++23") TemplateCxx23Ext {}; // cxx20-note {{'TemplateCxx23Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx23Ext<void>); // cxx20-warning {{'TemplateCxx23Ext<void>' is a C++23 extension}}
+
+template <class>
+class EXTENSION("C++26") TemplateCxx26Ext {}; // cxx23-note {{'TemplateCxx26Ext<void>' has been explicitly marked as an extension here}}
+
+void consume(TemplateCxx26Ext<void>); // cxx23-warning {{'TemplateCxx26Ext<void>' is a C++2c extension}}

clang/tools/libclang/CIndex.cpp

 
 static CXAvailabilityKind getCursorAvailabilityForDecl(const Decl *D) {
   if (isa<FunctionDecl>(D) && cast<FunctionDecl>(D)->isDeleted())
     return CXAvailability_NotAvailable;
 
   switch (D->getAvailability()) {
   case AR_Available:
   case AR_NotYetIntroduced:
+  case AR_Extension:
     if (const EnumConstantDecl *EnumConst = dyn_cast<EnumConstantDecl>(D))
       return getCursorAvailabilityForDecl(
           cast<Decl>(EnumConst->getDeclContext()));
     return CXAvailability_Available;
 
   case AR_Deprecated:
     return CXAvailability_Deprecated;