[libcxx-commits] [libcxx] 5c88aa9 - [libc++] Document the de-facto status of compiler extension support (#110877)

[via libcxx-commits]

Author: Louis Dionne
Date: 2024-10-07T17:27:29-04:00
New Revision: 5c88aa9d34c37f100be60269cfad6b8354918536

URL: https://github.com/llvm/llvm-project/commit/5c88aa9d34c37f100be60269cfad6b8354918536
DIFF: https://github.com/llvm/llvm-project/commit/5c88aa9d34c37f100be60269cfad6b8354918536.diff

LOG: [libc++] Document the de-facto status of compiler extension support (#110877)

This was brought up in a maintainer's meeting a few months ago. This
simply documents the current status quo.

Added: 
    

Modified: 
    libcxx/docs/UserDocumentation.rst

Removed: 
    


################################################################################
diff  --git a/libcxx/docs/UserDocumentation.rst b/libcxx/docs/UserDocumentation.rst
index 6659fa54f49df5..f5e55994aa7572 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -317,6 +317,15 @@ Unpoisoning may not be an option, if (for example) you are not maintaining the a
 * You are using allocator, which does not call destructor during deallocation.
 * You are aware that memory allocated with an allocator may be accessed, even when unused by container.
 
+Support for compiler extensions
+-------------------------------
+
+Clang, GCC and other compilers all provide their own set of language extensions. These extensions
+have often been developed without particular consideration for their interaction with the library,
+and as such, libc++ does not go out of its way to support them. The library may support specific
+compiler extensions which would then be documented explicitly, but the basic expectation should be
+that no special support is provided for arbitrary compiler extensions.
+
 Platform specific behavior
 ==========================