https://github.com/ldionne updated 
https://github.com/llvm/llvm-project/pull/96116

>From 4044e7c930381e5e070c7131c5b14a3dfd373259 Mon Sep 17 00:00:00 2001
From: Louis Dionne <ldionn...@gmail.com>
Date: Wed, 19 Jun 2024 16:50:07 -0400
Subject: [PATCH 1/2] [libc++] Add release note for #95264

---
 libcxx/docs/ReleaseNotes/18.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/libcxx/docs/ReleaseNotes/18.rst b/libcxx/docs/ReleaseNotes/18.rst
index 7ea13e6943dd4..3e19e7c33f6af 100644
--- a/libcxx/docs/ReleaseNotes/18.rst
+++ b/libcxx/docs/ReleaseNotes/18.rst
@@ -328,6 +328,15 @@ ABI Affecting Changes
   done to fix `#70494 <https://github.com/llvm/llvm-project/issues/70494>`_ 
and the vendor communication is handled
   in `#70820 <https://github.com/llvm/llvm-project/issues/70820>`_.
 
+- LLVM 18.1.8 Fixed an issue that caused ``std::string`` to pass an incorrect 
size to ``allocator_traits::deallocate``
+  when deallocating memory. The impact is different depending on a few factors:
+  - Users who don't use a custom allocator in ``std::string`` and don't enable 
sized deallocation (which is
+    off by default in Clang 18) will not be affected. This is expected to be 
the vast majority of users.
+  - Users who don't use a custom allocator in ``std::string`` but are enabling 
sized deallocation (e.g. with
+    ``-fsized-deallocation``) will notice that ``operator delete(void*, 
size_t)`` is now being passed the correct
+    size. This likely has no impact if they were not customizing ``operator 
delete``.
+  - Users who use a custom allocator in ``std::string`` will notice that they 
now get passed the correct allocation
+    size upon deallocation.
 
 Build System Changes
 --------------------

>From 99a23b574283752ffdc69934c32f9f825ddf10ed Mon Sep 17 00:00:00 2001
From: Louis Dionne <ldionn...@gmail.com>
Date: Thu, 20 Jun 2024 13:46:04 -0400
Subject: [PATCH 2/2] Try to fix RST syntax error

---
 libcxx/docs/ReleaseNotes/18.rst | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libcxx/docs/ReleaseNotes/18.rst b/libcxx/docs/ReleaseNotes/18.rst
index 3e19e7c33f6af..f7c269acda8b2 100644
--- a/libcxx/docs/ReleaseNotes/18.rst
+++ b/libcxx/docs/ReleaseNotes/18.rst
@@ -330,13 +330,14 @@ ABI Affecting Changes
 
 - LLVM 18.1.8 Fixed an issue that caused ``std::string`` to pass an incorrect 
size to ``allocator_traits::deallocate``
   when deallocating memory. The impact is different depending on a few factors:
-  - Users who don't use a custom allocator in ``std::string`` and don't enable 
sized deallocation (which is
-    off by default in Clang 18) will not be affected. This is expected to be 
the vast majority of users.
-  - Users who don't use a custom allocator in ``std::string`` but are enabling 
sized deallocation (e.g. with
-    ``-fsized-deallocation``) will notice that ``operator delete(void*, 
size_t)`` is now being passed the correct
-    size. This likely has no impact if they were not customizing ``operator 
delete``.
-  - Users who use a custom allocator in ``std::string`` will notice that they 
now get passed the correct allocation
-    size upon deallocation.
+
+    - Users who don't use a custom allocator in ``std::string`` and don't 
enable sized deallocation (which is
+      off by default in Clang 18) will not be affected. This is expected to be 
the vast majority of users.
+    - Users who don't use a custom allocator in ``std::string`` but are 
enabling sized deallocation (e.g. with
+      ``-fsized-deallocation``) will notice that ``operator delete(void*, 
size_t)`` is now being passed the correct
+      size. This likely has no impact if they were not customizing ``operator 
delete``.
+    - Users who use a custom allocator in ``std::string`` will notice that 
they now get passed the correct allocation
+      size upon deallocation.
 
 Build System Changes
 --------------------

_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to