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

Louis Dionne via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 18 09:56:26 PDT 2023


ldionne added a comment.

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.



================
Comment at: clang/include/clang/Basic/AttrDocs.td:1741
+    template <class CharT, class Traits = char_traits<CharT>>
+    class [[clang::extension("C++17")]] basic_string_view { /*...*/ };
+
----------------
This should say `clang::library_extension`


================
Comment at: clang/include/clang/Basic/AttrDocs.td:1746
+
+  // Clang produces the warning "std::string_view is a C++17 extension"
+  void func(std::string_view);
----------------
ldionne wrote:
> 
Perhaps the diagnostic should be `std::string_view is a C++17 library extension`?


================
Comment at: clang/include/clang/Basic/AttrDocs.td:1746-1747
+
+  // Clang produces the warning "std::string_view is a C++17 extension"
+  void func(std::string_view);
+
----------------



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D157572/new/

https://reviews.llvm.org/D157572



More information about the cfe-commits mailing list