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

[Louis Dionne via libcxx-commits]

https://github.com/ldionne created https://github.com/llvm/llvm-project/pull/110877

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

>From 13b5a47ab412ad3efdd09a4b3f2c8a0be57cdd4a Mon Sep 17 00:00:00 2001
From: Louis Dionne <ldionne.2 at gmail.com>
Date: Wed, 2 Oct 2024 12:09:30 -0400
Subject: [PATCH] [libc++] Document the de-facto status of compiler extension
 support

This was brought up in a maintainer's meeting a few months ago. This
simply documents the current status quo.
---
 libcxx/docs/UserDocumentation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

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
 ==========================