[llvm-branch-commits] [clang] [analyzer][docs] CSA release notes for clang-20 (PR #124798)

[Donát Nagy via llvm-branch-commits]

================
@@ -1356,30 +1356,62 @@ Static Analyzer
 New features
 ^^^^^^^^^^^^
 
-- Now CSA models `__builtin_*_overflow` functions. (#GH102602)
+- The ``__builtin_*_overflow`` functions are now properly modeled. (#GH102602)
 
-- MallocChecker now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)``
-  attributes with class names different from "malloc". Clang static analyzer now reports an error
-  if class of allocation and deallocation function mismatches.
+- ``unix.Malloc`` now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)``
+  attributes with class names different from "malloc". It now reports an error
+  if the class of allocation and deallocation function mismatches.
   `Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-mismatcheddeallocator-c-c>`__.
 
 - Function effects, e.g. the ``nonblocking`` and ``nonallocating`` "performance constraint"
   attributes, are now verified. For example, for functions declared with the ``nonblocking``
-  attribute, the compiler can generate warnings about the use of any language features, or calls to
+  attribute, the compiler can generate warnings about the use of any language features or calls to
   other functions, which may block.
 
 - Introduced ``-warning-suppression-mappings`` flag to control diagnostic
-  suppressions per file. See `documentation <https://clang.llvm.org/docs/WarningSuppressionMappings.html>_` for details.
+  suppressions per file. See `documentation <https://clang.llvm.org/docs/WarningSuppressionMappings.html>`__ for details.
+
+- Started to model GCC asm statements in some basic way. (#GH103714, #GH109838)
 
 Crash and bug fixes
 ^^^^^^^^^^^^^^^^^^^
 
 - In loops where the loop condition is opaque (i.e. the analyzer cannot
   determine whether it's true or false), the analyzer will no longer assume
-  execution paths that perform more that two iterations. These unjustified
+  execution paths that perform more than two iterations. These unjustified
   assumptions caused false positive reports (e.g. 100+ out-of-bounds reports in
   the FFMPEG codebase) in loops where the programmer intended only two or three
   steps but the analyzer wasn't able to understand that the loop is limited.
+  Read the `RFC <https://discourse.llvm.org/t/loop-handling-improvement-plans/80417/17>`_
+  for details. (#GH119388)
----------------
NagyDonat wrote:

```suggestion
  (#GH119388)
```
I wouldn't link the loop improvement discourse thread here, because I think the (fairly detailed) github PR description and its discussion is sufficient for understanding the goals of this change -- while the discourse thread mostly contains confusing descriptions of obsolete, abandoned plans that are just tangentially related to this commit.

https://github.com/llvm/llvm-project/pull/124798