Move rest of documentation problems that found their way to the SA section #154608
Conversation
|
@llvm/pr-subscribers-clang Author: Erich Keane (erichkeane) ChangesIt was brought up in response to #154605 that these two were in the wrong place as well! This patch tries to find better places for them, Full diff: https://github.com/llvm/llvm-project/pull/154608.diff 1 Files Affected:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f4f7dd8342d92..0745c6117cbea 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -123,6 +123,8 @@ C++ Language Changes
a perfect match (all conversion sequences are identity conversions) template candidates are not instantiated.
Diagnostics that would have resulted from the instantiation of these template candidates are no longer
produced. This aligns Clang closer to the behavior of GCC, and fixes (#GH62096), (#GH74581), and (#GH74581).
+- Implemented `P2719R5 Type-aware allocation and deallocation functions <https://wg21.link/P2719>`_
+ as an extension in all C++ language modes.
C++2c Feature Support
^^^^^^^^^^^^^^^^^^^^^
@@ -378,6 +380,11 @@ New Compiler Flags
- New options ``-fthinlto-distributor=`` and ``-Xthinlto-distributor=`` added for Integrated Distributed ThinLTO (DTLTO). DTLTO enables the distribution of backend ThinLTO compilations via external distribution systems, such as Incredibuild, during the traditional link step. (#GH147265, `ThinLTODocs <https://clang.llvm.org/docs/ThinLTO.html#integrated-distributed-thinlto-dtlto>`_).
+- A new flag - `-static-libclosure` was introduced to support statically linking
+ the runtime for the Blocks extension on Windows. This flag currently only
+ changes the code generation, and even then, only on Windows. This does not
+ impact the linker behaviour like the other `-static-*` flags.
+
Deprecated Compiler Flags
-------------------------
@@ -1204,26 +1211,6 @@ Static Analyzer
New features
^^^^^^^^^^^^
-- A new flag - `-static-libclosure` was introduced to support statically linking
- the runtime for the Blocks extension on Windows. This flag currently only
- changes the code generation, and even then, only on Windows. This does not
- impact the linker behaviour like the other `-static-*` flags.
-- OpenACC support, enabled via `-fopenacc` has reached a level of completeness
- to finally be at least notionally usable. Currently, the OpenACC 3.4
- specification has been completely implemented for Sema and AST creation, so
- nodes will show up in the AST after having been properly checked. Lowering is
- currently a work in progress, with compute, loop, and combined constructs
- partially implemented, plus a handful of data and executable constructs
- implemented. Lowering will only work in Clang-IR mode (so only with a compiler
- built with Clang-IR enabled, and with `-fclangir` used on the command line).
- However, note that the Clang-IR implementation status is also quite partial,
- so frequent 'not yet implemented' diagnostics should be expected. Also, the
- ACC MLIR dialect does not currently implement any lowering to LLVM-IR, so no
- code generation is possible for OpenACC.
-- Implemented `P2719R5 Type-aware allocation and deallocation functions <https://wg21.link/P2719>`_
- as an extension in all C++ language modes.
-
-
Crash and bug fixes
^^^^^^^^^^^^^^^^^^^
|
|
Thank you for going the extra mile. |
|
This has conflicts towards the release branch - can someone look at fixing this? |
|
Dammit, yeah I wish I could still see the conflict to work out how I misread it - I suspect the addition of "A new flag - |
You can actually, |
I think this was a pebkac issue with me using the GH editor to resolve the diff - if I merge locally the change seems obvious, and I can't think of a reason to make this error. |
Thank you so much for fixing this :) I appreciate your help! |
|
Seems like this still have conflicts? do you have time to look at this now @steakhal ? otherwise I'll make an attempt at resolving it before the final release tomorrow, but it would be better if you did it since you know what to expect. |
There was nothing serious. The default git merge strategy resolved it automatically using "ort". |
5c6f47f to
2b5beba
Compare
|
I had to squash and merge because of how stupid github is - I hope I got it right :( |
It was brought up in response to llvm#154605 that these two were in the wrong place as well! This patch tries to find better places for them, and moves them.
|
@erichkeane (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR. |
it really is terrible :-/ |
It was brought up in response to #154605 that these two were in the wrong place as well! This patch tries to find better places for them,
and moves them.