[clang][NFC] Remove trailing whitespaces and enforce it in lib, include and docs

[philnik]

Summary

A lot of editors remove trailing whitespaces. This patch removes any trailing whitespaces and makes sure that no new ones are added.

[paulkirth]

NOTE: Clang-Format Team Automated Review Comment

Your review contains a change to ClangFormatStyleOptions.rst but not a change to clang/include/clang/Format/Format.h

ClangFormatStyleOptions.rst is auto generated from Format.h via clang/docs/tools/dump_format_style.py, please run this to regenerate the .rst

You can validate that the rst is valid by running.

./docs/tools/dump_format_style.py
mkdir -p html
/usr/bin/sphinx-build -n ./docs ./html

[erichkeane]

This looks fine to me. HOWEVER, please make sure to add this commit to https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs in a follow-up NFC commit.

[paulkirth]

Also LGTM for the changes in MisExpect.rst, modulo feedback from @erichkeane.

[aaron.ballman]

In D151963#4390675, @erichkeane wrote:

This looks fine to me. HOWEVER, please make sure to add this commit to https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs in a follow-up NFC commit.

Please be sure to do this.

[aaron.ballman]

In D151963#4449346, @aaron.ballman wrote:

In D151963#4390675, @erichkeane wrote:

This looks fine to me. HOWEVER, please make sure to add this commit to https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs in a follow-up NFC commit.

Please be sure to do this.

This did get handled, thanks! Today I learned that changes to the top level in the monorepo don't make it to either of the llvm-commits or cfe-commits mailing lists.

[ldionne]

libcxx/utils/ci/buildkite-pipeline-clang.yml

20–31

Something in here broke the Clang CI. See for example https://buildkite.com/llvm-project/libcxx-ci/builds/27050#0188fe23-c359-4a1d-8d10-f0fb966f142e.

It's actually interesting, now the libc++ CI is lightning fast since we're not sharing our resources anymore. I'll follow-up on that, I never expected it to make such a huge difference.

[eddyz87]

libcxx/utils/ci/buildkite-pipeline-clang.yml

20–31

I believe it's the following line:

commands:
  - "! grep -rnI '[[:blank:]]$' clang/lib clang/include clang/docs || false"

buildkite-agent interpolates variables in commands and reacts to $, so it should be:

commands:
  - "! grep -rnI '[[:blank:]]$$' clang/lib clang/include clang/docs || false"

Instead (note $$).

It is possible to test this locally using the following commands:

$ ./libcxx/utils/ci/generate-buildkite-pipeline > 1.ym
$ docker run -v `realpath 1.yml`:`realpath 1.yml` \
      --rm buildkite/agent:3 pipeline upload --dry-run \
      --agent-access-token xx `realpath 1.yml`
2023-06-30 14:36:35 INFO   Reading pipeline config from "/home/eddy/work/llvm-project/1.yml"
2023-06-30 14:36:35 FATAL  Pipeline parsing of "1.yml" failed (Expected identifier to start with a letter, got ')

The error is gone if '$$' change is applied. (But I have not tested if semantics of the command is preserved).
As far as I understand this link applies here.

clang/docs/ClangFormatStyleOptions.rst

* ``BAS_BlockIndent`` (in configuration: ``BlockIndent``)
 
     .. code-block:: c++
 
       someLongFunction(
           argument1, argument2
       )
 
 
-    .. warning:: 
+    .. warning::
 
      Note: This currently only applies to parentheses.
 
 
 
 .. _AlignArrayOfStructures:
 
 **AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <AlignArrayOfStructures>`

 
 .. _InsertBraces:
 
 **InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <InsertBraces>`
   Insert braces after control statements (``if``, ``else``, ``for``, ``do``,
   and ``while``) in C++ unless the control statements are inside macro
   definitions or the braces would enclose preprocessor directives.
 
-  .. warning:: 
+  .. warning::
 
    Setting this option to `true` could lead to incorrect code formatting due
    to clang-format's lack of complete semantic information. As such, extra
    care should be taken to review code changes made by this option.
 
   .. code-block:: c++
 
     false:                                    true:

 
 
 
 .. _QualifierAlignment:
 
 **QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierAlignment>`
   Different ways to arrange specifiers and qualifiers (e.g. const/volatile).
 
-  .. warning:: 
+  .. warning::
 
    Setting ``QualifierAlignment``  to something other than `Leave`, COULD
    lead to incorrect code formatting due to incorrect decisions made due to
    clang-formats lack of complete semantic information.
    As such extra care should be taken to review code changes made by the use
    of this option.
 
   Possible values:
/* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
       * information */
 
 .. _RemoveBracesLLVM:
 
 **RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ <RemoveBracesLLVM>`
   Remove optional braces of control statements (``if``, ``else``, ``for``,
   and ``while``) in C++ according to the LLVM coding style.
 
-  .. warning:: 
+  .. warning::
 
    This option will be renamed and expanded to support other styles.
 
-  .. warning:: 
+  .. warning::
 
    Setting this option to `true` could lead to incorrect code formatting due
    to clang-format's lack of complete semantic information. As such, extra
    care should be taken to review code changes made by this option.
 
   .. code-block:: c++
 
     false:                                     true:
if (a) {                           vs.     if (a)
       }
     }
 
 .. _RemoveSemicolon:
 
 **RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <RemoveSemicolon>`
   Remove semicolons after the closing brace of a non-empty function.
 
-  .. warning:: 
+  .. warning::
 
    Setting this option to `true` could lead to incorrect code formatting due
    to clang-format's lack of complete semantic information. As such, extra
    care should be taken to review code changes made by this option.
 
   .. code-block:: c++
 
     false:                                     true:

clang/docs/ClangLinkerWrapper.rst

 =====
 
 This tool can be used with the following options. Any arguments not intended
 only for the linker wrapper will be forwarded to the wrapped linker job.
 
 .. code-block:: console
 
   USAGE: clang-linker-wrapper [options] -- <options to passed to the linker>
-  
   OPTIONS:
     --bitcode-library=<kind>-<triple>-<arch>=<path>
                            Extra bitcode library to link
     --cuda-path=<dir>      Set the system CUDA path
     --device-debug         Use debugging
     --device-linker=<value> or <triple>=<value>
                            Arguments to pass to the device linker invocation
     --dry-run              Print program arguments without running

clang/docs/ClangOffloadPackager.rst

 bundled together by simply concatenating them in this format. Because we have
 the magic bytes and size of each image, we can extract them as-needed.
 
 Usage
 =====
 
 This tool can be used with the following arguments. Generally information is
 passed as a key-value pair to the ``image=`` argument. The ``file`` and ``triple``,
-arguments are considered mandatory to make a valid image. The ``arch`` argument 
+arguments are considered mandatory to make a valid image. The ``arch`` argument
 is suggested.
 
 .. code-block:: console
 
   OVERVIEW: A utility for bundling several object files into a single binary.
   The output binary can then be embedded into the host section table
   to create a fatbinary containing offloading code.
-  
   USAGE: clang-offload-packager [options]
-  
   OPTIONS:
-  
   Generic Options:
-  
     --help                      - Display available options (--help-hidden for more)
     --help-list                 - Display list of available options (--help-list-hidden for more)
     --version                   - Display the version of this program
-  
   clang-offload-packager options:
-  
     --image=<<key>=<value>,...> - List of key and value arguments. Required
                                   keywords are 'file' and 'triple'.
     -o <file>                   - Write output to <file>.
 
 Example
 =======
 
 This tool simply takes many input files from the ``image`` option and creates a
 single output file with all the images combined.
 
 .. code-block:: console
 
   clang-offload-packager -o out.bin --image=file=input.o,triple=nvptx64,arch=sm_70
 
-The inverse operation can be performed instead by passing the packaged binary as 
-input. In this mode the matching images will either be placed in the output 
-specified by the ``file`` option. If no ``file`` argument is provided a name 
+The inverse operation can be performed instead by passing the packaged binary as
+input. In this mode the matching images will either be placed in the output
+specified by the ``file`` option. If no ``file`` argument is provided a name
 will be generated for each matching image.
 
 .. code-block:: console
 
   clang-offload-packager in.bin --image=file=output.o,triple=nvptx64,arch=sm_70

clang/docs/ClangTransformerTutorial.rst

 tools to modify a large number of C++ files in (roughly) the same way. What
 qualifies as "large" really depends on the nature of the change and your
 patience for repetitive editing. In our experience, automated solutions become
 worthwhile somewhere between 100 and 500 files.
 
 Getting Started
 ---------------
 
-Patterns in Transformer are expressed with :doc:`clang's AST matchers <LibASTMatchers>`. 
+Patterns in Transformer are expressed with :doc:`clang's AST matchers <LibASTMatchers>`.
 Matchers are a language of combinators for describing portions of a clang
 Abstract Syntax Tree (AST). Since clang's AST includes complete type information
 (within the limits of single `Translation Unit (TU)`_,
 these patterns can even encode rich constraints on the type properties of AST
 nodes.
 
 .. _`Translation Unit (TU)`: https://en.wikipedia.org/wiki/Translation_unit_\(programming\)
 
 We assume a familiarity with the clang AST and the corresponding AST matchers
 for the purpose of this tutorial. Users who are unfamiliar with either are
 encouraged to start with the recommended references in `Related Reading`_.
 
 Example: style-checking names
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Assume you have a style-guide rule which forbids functions from being named
 "MkX" and you want to write a check that catches any violations of this rule. We
 can express this a Transformer rewrite rule:
 
 .. code-block:: c++
-    
    makeRule(functionDecl(hasName("MkX").bind("fun"),
       noopEdit(node("fun")),
       cat("The name ``MkX`` is not allowed for functions; please rename"));
 
 ``makeRule`` is our go-to function for generating rewrite rules. It takes three
 arguments: the pattern, the edit, and (optionally) an explanatory note. In our
 example, the pattern (``functionDecl(...)``) identifies the declaration of the
 function ``MkX``. Since we're just diagnosing the problem, but not suggesting a

 
 Example: renaming a function
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Now, let's extend this example to a *transformation*; specifically, the second
 example above:
 
 .. code-block:: c++
-    
    makeRule(declRefExpr(to(functionDecl(hasName("MkX")))),
       changeTo(cat("MakeX")),
       cat("MkX has been renamed MakeX"));
 
 In this example, the pattern (``declRefExpr(...)``) identifies any *reference* to
 the function ``MkX``, rather than the declaration itself, as in our previous
 example. Our edit (``changeTo(...)``) says to *change* the code matched by the
 pattern *to* the text "MakeX". Finally, we use ``cat`` again to build a message

 
 Next, let's write a rule to replace a method call with a (free) function call,
 applied to the original method call's target object. Specifically, "change
 ``s.size()`` to ``Size(s)``, where ``s`` is a ``string``." We start with a simpler
 change that ignores the type of ``s``. That is, it will modify *any* method call
 where the method is named "size":
 
 .. code-block:: c++
-    
    llvm::StringRef s = "str";
    makeRule(
      cxxMemberCallExpr(
        on(expr().bind(s)),
        callee(cxxMethodDecl(hasName("size")))),
      changeTo(cat("Size(", node(s), ")")),
      cat("Method ``size`` is deprecated in favor of free function ``Size``"));
 
 We express the pattern with the given AST matcher, which binds the method call's
 target to ``s`` [#f1]_. For the edit, we again use ``changeTo``, but this
 time we construct the term from multiple parts, which we compose with ``cat``. The
 second part of our term is ``node(s)``, which selects the source code
 corresponding to the AST node ``s`` that was bound when a match was found in the
 AST for our rule's pattern. ``node(s)`` constructs a ``RangeSelector``, which, when
 used in ``cat``, indicates that the selected source should be inserted in the
 output at that point.
 
 Now, we probably don't want to rewrite *all* invocations of "size" methods, just
 those on ``std::string``\ s. We can achieve this change simply by refining our
 matcher. The rest of the rule remains unchanged:
 
 .. code-block:: c++
-    
    llvm::StringRef s = "str";
    makeRule(
      cxxMemberCallExpr(
        on(expr(hasType(namedDecl(hasName("std::string"))))
    .bind(s)),
        callee(cxxMethodDecl(hasName("size")))),
      changeTo(cat("Size(", node(s), ")")),
      cat("Method ``size`` is deprecated in favor of free function ``Size``"));
 
 Example: rewriting method calls
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In this example, we delete an "intermediary" method call in a string of
 invocations. This scenario can arise, for example, if you want to collapse a
 substructure into its parent.
 
 .. code-block:: c++
-    
    llvm::StringRef e = "expr", m = "member";
    auto child_call = cxxMemberCallExpr(on(expr().bind(e)),
                callee(cxxMethodDecl(hasName("child"))));
    makeRule(cxxMemberCallExpr(on(child_call), callee(memberExpr().bind(m)),
       changeTo(cat(e, ".", member(m), "()"))),
       cat("``child`` accessor is being removed; call ",
     member(m), " directly on parent"));
 
 This rule isn't quite what we want: it will rewrite ``my_object.child().foo()`` to
 ``my_object.foo()``, but it will also rewrite ``my_ptr->child().foo()`` to
 ``my_ptr.foo()``, which is not what we intend. We could fix this by restricting
 the pattern with ``not(isArrow())`` in the definition of ``child_call``. Yet, we
 *want* to rewrite calls through pointers.
 
 To capture this idiom, we provide the ``access`` combinator to intelligently
 construct a field/method access. In our example, the member access is expressed
 as:
 
 .. code-block:: c++
-    
    access(e, cat(member(m)))
 
 The first argument specifies the object being accessed and the second, a
 description of the field/method name. In this case, we specify that the method
 name should be copied from the source -- specifically, the source range of ``m``'s
 member. To construct the method call, we would use this expression in ``cat``:
 
 .. code-block:: c++
-    
    cat(access(e, cat(member(m))), "()")
 
 Reference: ranges, stencils, edits, rules
 -----------------------------------------
 
 The above examples demonstrate just the basics of rewrite rules. Every element
 we touched on has more available constructors: range selectors, stencils, edits
 and rules. In this section, we'll briefly review each in turn, with references

 ^^^^^
 
 Transformer supports additional forms of edits. First, in a ``changeTo``, we can
 specify the particular portion of code to be replaced, using the same
 ``RangeSelector`` we saw earlier. For example, we could change the function name
 in a function declaration with:
 
 .. code-block:: c++
-    
    makeRule(functionDecl(hasName("bad")).bind(f),
       changeTo(name(f), cat("good")),
       cat("bad is now good"));
 
 We also provide simpler editing primitives for insertion and deletion:
 ``insertBefore``, ``insertAfter`` and ``remove``. These can all be found in the header
 file
 `clang/Tooling/Transformer/RewriteRule.h <https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Tooling/Transformer/RewriteRule.h>`_.
 
 We are not limited one edit per match found. Some situations require making
 multiple edits for each match. For example, suppose we wanted to swap two
 arguments of a function call.
 
 For this, we provide an overload of ``makeRule`` that takes a list of edits,
 rather than just a single one. Our example might look like:
 
 .. code-block:: c++
-    
    makeRule(callExpr(...),
      {changeTo(node(arg0), cat(node(arg2))),
       changeTo(node(arg2), cat(node(arg0)))},
      cat("swap the first and third arguments of the call"));
 
 ``EditGenerator``\ s (Advanced)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The particular edits we've seen so far are all instances of the ``ASTEdit`` class,
 or a list of such. But, not all edits can be expressed as ``ASTEdit``\ s. So, we
 also support a very general signature for edit generators:
 
 .. code-block:: c++
-    
    using EditGenerator = MatchConsumer<llvm::SmallVector<Edit, 1>>;
 
 That is, an ``EditGenerator`` is function that maps a ``MatchResult`` to a set
 of edits, or fails. This signature supports a very general form of computation
 over match results. Transformer provides a number of functions for working with
 ``EditGenerator``\ s, most notably
 `flatten <https://github.com/llvm/llvm-project/blob/1fabe6e51917bcd7a1242294069c682fe6dffa45/clang/include/clang/Tooling/Transformer/RewriteRule.h#L165-L167>`_
 ``EditGenerator``\ s, like list flattening. For the full list, see the header file

 The benefit of ``applyFirst`` is that, for some problems, it allows the user to
 more concisely formulate later rules in the list, since their patterns need not
 explicitly exclude the earlier patterns of the list. For example, consider a set
 of rules that rewrite compound statements, where one rule handles the case of an
 empty compound statement and the other handles non-empty compound statements.
 With ``applyFirst``, these rules can be expressed compactly as:
 
 .. code-block:: c++
-    
    applyFirst({
      makeRule(compoundStmt(statementCountIs(0)).bind("empty"), ...),
      makeRule(compoundStmt().bind("non-empty"),...)
    })
 
 The second rule does not need to explicitly specify that the compound statement
 is non-empty -- it follows from the rules position in ``applyFirst``. For more
 complicated examples, this can lead to substantially more readable code.

clang/docs/DebuggingCoroutines.rst

.. code-block:: c++
   #include <coroutine>
   #include <iostream>
   #include <utility>
 
   struct task {
     struct promise_type {
       task get_return_object();
       std::suspend_always initial_suspend() { return {}; }
-      
       void unhandled_exception() noexcept {}
 
       struct FinalSuspend {
         std::coroutine_handle<> continuation;
         auto await_ready() noexcept { return false; }
         auto await_suspend(std::coroutine_handle<> handle) noexcept {
           return continuation;
         }

clang/docs/ExternalClangExamples.rst

 Clang's library-based design is deliberately aimed at facilitating use by
 external projects, and we are always interested in improving Clang to
 better serve our external users. Some typical categories of applications
 where Clang is used are:
 
 - Static analysis.
 - Documentation/cross-reference generation.
 
-If you know of (or wrote!) a tool or project using Clang, please post on 
+If you know of (or wrote!) a tool or project using Clang, please post on
 `the Discourse forums (Clang Frontend category)
 <https://discourse.llvm.org/c/clang/6>`_ to have it added.
 (or if you are already a Clang contributor, feel free to directly commit
 additions). Since the primary purpose of this page is to provide examples
 that can help developers, generally they must have code available.
 
 List of projects and tools
 ==========================

clang/docs/JSONCompilationDatabase.rst

 
 Currently `CMake <https://cmake.org>`_ (since 2.8.5) supports generation
 of compilation databases for Unix Makefile builds (Ninja builds in the
 works) with the option ``CMAKE_EXPORT_COMPILE_COMMANDS``.
 
 For projects on Linux, there is an alternative to intercept compiler
 calls with a tool called `Bear <https://github.com/rizsotto/Bear>`_.
 
-`Bazel <https://bazel.build>`_ can export a compilation database via 
-`this extractor extension 
+`Bazel <https://bazel.build>`_ can export a compilation database via
+`this extractor extension
 <https://github.com/hedronvision/bazel-compile-commands-extractor>`_.
 Bazel is otherwise resistant to Bear and other compiler-intercept
 techniques.
 
 Clang's tooling interface supports reading compilation databases; see
 the :doc:`LibTooling documentation <LibTooling>`. libclang and its
 python bindings also support this (since clang 3.2); see
 `CXCompilationDatabase.h </doxygen/group__COMPILATIONDB.html>`_.

 ::
 
     -xc++
     -I
     libwidget/include/
 
 Here ``-I libwidget/include`` is two arguments, and so becomes two lines.
 Paths are relative to the directory containing ``compile_flags.txt``.
-

clang/docs/MisExpect.rst

 ===================
 Misexpect
 ===================
 .. contents::
 
 .. toctree::
    :maxdepth: 1
 
 When developers use ``llvm.expect`` intrinsics, i.e., through use of
 ``__builtin_expect(...)``, they are trying to communicate how their code is
 expected to behave at runtime to the optimizer. These annotations, however, can
 be incorrect for a variety of reasons: changes to the code base invalidate them
 silently, the developer mis-annotated them (e.g., using ``LIKELY`` instead of
 ``UNLIKELY``), or perhaps they assumed something incorrectly when they wrote
 the annotation. Regardless of why, it is useful to detect these situations so
-that the optimizer can make more useful decisions about the code. 
+that the optimizer can make more useful decisions about the code.
 
 MisExpect diagnostics are intended to help developers identify and address
 these situations, by comparing the branch weights added by the ``llvm.expect``
 intrinsic to those collected through profiling. Whenever these values are
 mismatched, a diagnostic is surfaced to the user. Details on how the checks
 operate in the LLVM backed can be found in LLVM's documentation.
 
 By default MisExpect checking is quite strict, because the use of the

 
 .. option:: -Wmisexpect
 
   Enables misexpect warnings when profiling data conflicts with use of
   ``llvm.expect`` intrinsics.
 
 .. option:: -fdiagnostic-misexpect-tolerance=N
 
-   Relaxes misexpect checking to tolerate profiling values within N% of the 
+   Relaxes misexpect checking to tolerate profiling values within N% of the
    expected branch weight. e.g., a value of ``N=5`` allows misexpect to check against
    ``0.95 * Threshold``
 
 LLVM supports 4 types of profile formats: Frontend, IR, CS-IR, and
 Sampling. MisExpect Diagnostics are compatible with all Profiling formats.
 
 +----------------+--------------------------------------------------------------------------------------+
 | Profile Type   | Description                                                                          |
 +================+======================================================================================+
 | Frontend       | Profiling instrumentation added during compilation by the frontend, i.e. ``clang``   |
 +----------------+--------------------------------------------------------------------------------------+
 | IR             | Profiling instrumentation added during by the LLVM backend                           |
 +----------------+--------------------------------------------------------------------------------------+
 | CS-IR          | Context Sensitive IR based profiles                                                  |
 +----------------+--------------------------------------------------------------------------------------+
 | Sampling       | Profiles collected through sampling with external tools, such as ``perf`` on Linux   |
 +----------------+--------------------------------------------------------------------------------------+
-

clang/docs/ReleaseNotes.rst

- ``__declspec`` attributes can now be used together with the using keyword. Before
   point where the alias is used.
 - Introduced a new ``USR`` (unified symbol resolution) clause inside of the
   existing ``__attribute__((external_source_symbol))`` attribute. Clang's indexer
   uses the optional USR value when indexing Clang's AST. This value is expected
   to be generated by an external compiler when generating C++ bindings during
   the compilation of the foreign language sources (e.g. Swift).
 - The ``__has_attribute``, ``__has_c_attribute`` and ``__has_cpp_attribute``
   preprocessor operators now return 1 also for attributes defined by plugins.
-- Improve the AST fidelity of ``alignas`` and ``_Alignas`` attribute. Before, we 
+- Improve the AST fidelity of ``alignas`` and ``_Alignas`` attribute. Before, we
   model ``alignas(type-id)`` as though the user wrote ``alignas(alignof(type-id))``,
   now we directly use ``alignas(type-id)``.
 
 Improvements to Clang's diagnostics
 -----------------------------------
 - We now generate a diagnostic for signed integer overflow due to unary minus
   in a non-constant expression context.
   (`#31643 <https://github.com/llvm/llvm-project/issues/31643>`_)
- Address a false positive in ``-Wpacked`` when applied to a non-pod type using
   fallout from the non-POD packing ABI fix in LLVM 15).
 - Clang constexpr evaluator now prints subobject's name instead of its type in notes
   when a constexpr variable has uninitialized subobjects after its constructor call.
   (`#58601 <https://github.com/llvm/llvm-project/issues/58601>`_)
 - Clang's `-Wshadow` warning now warns about shadowings by static local variables
   (`#62850: <https://github.com/llvm/llvm-project/issues/62850>`_).
 - Clang now warns when any predefined macro is undefined or redefined, instead
   of only some of them.
-- Clang now correctly diagnoses when the argument to ``alignas`` or ``_Alignas`` 
+- Clang now correctly diagnoses when the argument to ``alignas`` or ``_Alignas``
   is an incomplete type.
   (`#55175: <https://github.com/llvm/llvm-project/issues/55175>`_, and fixes an
   incorrect mention of ``alignof`` in a diagnostic about ``alignas``).
 
 Bug Fixes in This Version
 -------------------------
 
 - Fix segfault while running clang-rename on a non existing file.

clang/docs/SourceBasedCodeCoverage.rst

 
 * "%t" expands out to the value of the ``TMPDIR`` environment variable. On
   Darwin, this is typically set to a temporary scratch directory.
 
 * "%Nm" expands out to the instrumented binary's signature. When this pattern
   is specified, the runtime creates a pool of N raw profiles which are used for
   on-line profile merging. The runtime takes care of selecting a raw profile
   from the pool, locking it, and updating it before the program exits.  If N is
-  not specified (i.e the pattern is "%m"), it's assumed that ``N = 1``. The 
+  not specified (i.e the pattern is "%m"), it's assumed that ``N = 1``. The
   merge pool specifier can only occur once per filename pattern.
 
 * "%c" expands out to nothing, but enables a mode in which profile counter
   updates are continuously synced to a file. This means that if the
   instrumented program crashes, or is killed by a signal, perfect coverage
   information can still be recovered. Continuous mode does not support value
   profiling for PGO, and is only supported on Darwin at the moment. Support for
   Linux may be mostly complete but requires testing, and support for Windows

clang/docs/StandardCPlusPlusModules.rst

 
 How to produce a BMI
 ~~~~~~~~~~~~~~~~~~~~
 
 We can generate a BMI for an importable module unit by either ``--precompile``
 or ``-fmodule-output`` flags.
 
 The ``--precompile`` option generates the BMI as the output of the compilation and the output path
-can be specified using the ``-o`` option. 
+can be specified using the ``-o`` option.
 
 The ``-fmodule-output`` option generates the BMI as a by-product of the compilation.
 If ``-fmodule-output=`` is specified, the BMI will be emitted the specified location. Then if
 ``-fmodule-output`` and ``-c`` are specified, the BMI will be emitted in the directory of the
 output file with the name of the input file with the new extension ``.pcm``. Otherwise, the BMI
 will be emitted in the working directory with the name of the input file with the new extension
 ``.pcm``.
 

 However, this is not true.
 Module units are translation units. We need to compile them to object files
 and link the object files like the example shows.
 
 For example, the traditional compilation processes for headers are like:
 
 .. code-block:: text
 
-  src1.cpp -+> clang++ src1.cpp --> src1.o ---, 
+  src1.cpp -+> clang++ src1.cpp --> src1.o ---,
   hdr1.h  --'                                 +-> clang++ src1.o src2.o ->  executable
   hdr2.h  --,                                 |
   src2.cpp -+> clang++ src2.cpp --> src2.o ---'
 
 And the compilation process for module units are like:
 
 .. code-block:: text
 
-                src1.cpp ----------------------------------------+> clang++ src1.cpp -------> src1.o -, 
+                src1.cpp ----------------------------------------+> clang++ src1.cpp -------> src1.o -,
   (header unit) hdr1.h    -> clang++ hdr1.h ...    -> hdr1.pcm --'                                    +-> clang++ src1.o mod1.o src2.o ->  executable
                 mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++ mod1.pcm ... -> mod1.o -+
                 src2.cpp ----------------------------------------+> clang++ src2.cpp -------> src2.o -'
 
 As the diagrams show, we need to compile the BMI from module units to object files and link the object files.
 (But we can't do this for the BMI from header units. See the later section for the definition of header units)
 
 If we want to create a module library, we can't just ship the BMIs in an archive.

 
 The language option of module units and their non-module-unit users should be consistent.
 The following example is not allowed:
 
 .. code-block:: c++
 
   // M.cppm
   export module M;
-  
   // Use.cpp
   import M;
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   $ clang++ -std=c++23 Use.cpp -fprebuilt-module-path=.
 
 The compiler would reject the example due to the inconsistent language options.
 Not all options are language options.
 For example, the following example is allowed:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 Use.cpp -fprebuilt-module-path=.
   # Inconsistent debugging level.
-  $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=. 
+  $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
 Although the two examples have inconsistent optimization and debugging level, both of them are accepted.
 
 Note that **currently** the compiler doesn't consider inconsistent macro definition a problem. For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm

 .. code-block:: console
 
   $ clang++ -std=c++20 -fimplicit-modules -fmodule-map-file=.modulemap main.cpp
 
 It would be simpler if we are using libcxx:
 
 .. code-block:: console
 
-  $ clang++ -std=c++20 main.cpp -fimplicit-modules -fimplicit-module-maps 
+  $ clang++ -std=c++20 main.cpp -fimplicit-modules -fimplicit-module-maps
 
 Since there is already one
 `module map <https://github.com/llvm/llvm-project/blob/main/libcxx/include/module.modulemap.in>`_
 in the source of libcxx.
 
 Then immediately leads to the question: why don't we implement header units through Clang header modules?
 
 The main reason for this is that Clang modules have more semantics like hierarchy or

 overload resolution and template instantiation.
 All of these processes are fast relative to the whole compilation process.
 More importantly, the imported code only needs to be processed once in frontend code generation,
 as well as the whole middle end and backend.
 So we could get a big win for the compilation time in O0.
 
 But with optimizations, things are different:
 
-(we omit ``code generation`` part for each end due to the limited space) 
+(we omit ``code generation`` part for each end due to the limited space)
 
 .. code-block:: none
 
   ├-------- frontend ---------┼--------------- middle end --------------------┼------ backend ----┤
   │                           │                                               │                   │
   └--- parsing ---- sema -----┴--- optimizations --- IPO ---- optimizations---┴--- optimizations -┘
-                                                                                                            
   ┌-----------------------------------------------------------------------------------------------┐
   │                                                                                               │
   │                                         source file                                           │
   │                                                                                               │
   └-----------------------------------------------------------------------------------------------┘
                 ┌---------------------------------------┐
                 │                                       │
                 │                                       │

 by optimizations (including IPO itself).
 The optimizations before IPO and the IPO itself are the most time-consuming part in whole compilation process.
 So from this perspective, we might not be able to get the improvements described in the theory.
 But we could still save the time for optimizations after IPO and the whole backend.
 
 Overall, at ``O0`` the implementations of functions defined in a module will not impact module users,
 but at higher optimization levels the definitions of such functions are provided to user compilations for the
 purposes of optimization (but definitions of these functions are still not included in the use's object file)-
-this means the build speedup at higher optimization levels may be lower than expected given ``O0`` experience, 
+this means the build speedup at higher optimization levels may be lower than expected given ``O0`` experience,
 but does provide by more optimization opportunities.
 
 Interoperability with Clang Modules
 -----------------------------------
 
 We **wish** to support clang modules and standard c++ modules at the same time,
 but the mixed using form is not well used/tested yet.
 
 Please file new github issues as you find interoperability problems.

clang/docs/UndefinedBehaviorSanitizer.rst

Available checks are:
   -  ``-fsanitize=shift``: Shift operators where the amount shifted is
      greater or equal to the promoted bit-width of the left hand side
      or less than zero, or where the left hand side is negative. For a
      signed left shift, also checks for signed overflow in C, and for
      unsigned overflow in C++. You can use ``-fsanitize=shift-base`` or
      ``-fsanitize=shift-exponent`` to check only left-hand side or
      right-hand side of shift operation, respectively.
   -  ``-fsanitize=unsigned-shift-base``: check that an unsigned left-hand side of
-     a left shift operation doesn't overflow. Issues caught by this sanitizer are 
+     a left shift operation doesn't overflow. Issues caught by this sanitizer are
      not undefined behavior, but are often unintentional.
   -  ``-fsanitize=signed-integer-overflow``: Signed integer overflow, where the
      result of a signed integer computation cannot be represented in its type.
      This includes all the checks covered by ``-ftrapv``, as well as checks for
      signed division overflow (``INT_MIN/-1``), but not checks for
      lossy implicit conversions performed before the computation
      (see ``-fsanitize=implicit-conversion``). Both of these two issues are
      handled by ``-fsanitize=implicit-conversion`` group of checks.

clang/docs/analyzer/checkers.rst

void test(int *p) {
    if (!p)
      f(p); // warn
  }
 
 .. _core-NullDereference:
 
 core.NullDereference (C, C++, ObjC)
 """""""""""""""""""""""""""""""""""
-Check for dereferences of null pointers. 
+Check for dereferences of null pointers.
 
 This checker specifically does
 not report null pointer dereferences for x86 and x86-64 targets when the
 address space is 256 (x86 GS Segment), 257 (x86 FS Segment), or 258 (x86 SS
 segment). See `X86/X86-64 Language Extensions
 <https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments>`__
 for reference.
 
-The ``SuppressAddressSpaces`` option suppresses 
+The ``SuppressAddressSpaces`` option suppresses
 warnings for null dereferences of all pointers with address spaces. You can
 disable this behavior with the option
 ``-analyzer-config core.NullDereference:SuppressAddressSpaces=false``.
 *Defaults to true*.
 
 .. code-block:: objc
 
  // C

 
 .. _alpha-unix-cstring-UninitializedRead:
 
 alpha.unix.cstring.UninitializedRead (C)
 """"""""""""""""""""""""""""""""""""""""
 Check for uninitialized reads from common memory copy/manipulation functions such as:
  ``memcpy, mempcpy, memmove, memcmp, strcmp, strncmp, strcpy, strlen, strsep`` and many more.
 
-.. code-block:: c 
+.. code-block:: c
 
  void test() {
   char src[10];
   char dst[5];
   memcpy(dst,src,sizeof(dst)); // warn: Bytes string function accesses uninitialized/garbage values
  }
 
 Limitations:
-  
    - Due to limitations of the memory modeling in the analyzer, one can likely
      observe a lot of false-positive reports like this:
 
       .. code-block:: c
-  
         void false_positive() {
           int src[] = {1, 2, 3, 4};
           int dst[5] = {0};
           memcpy(dst, src, 4 * sizeof(int)); // false-positive:
           // The 'src' buffer was correctly initialized, yet we cannot conclude
           // that since the analyzer could not see a direct initialization of the
           // very last byte of the source buffer.
         }
-  
      More details at the corresponding `GitHub issue <https://github.com/llvm/llvm-project/issues/43459>`_.
-  
 .. _alpha-nondeterminism-PointerIteration:
 
 alpha.nondeterminism.PointerIteration (C++)
 """""""""""""""""""""""""""""""""""""""""""
 Check for non-determinism caused by iterating unordered containers of pointers.
 
 .. code-block:: c
 

 """""""""""""""""""
 View Call Graph using GraphViz.
 
 .. _debug-ViewExplodedGraph:
 
 debug.ViewExplodedGraph
 """""""""""""""""""""""
 View Exploded Graphs using GraphViz.
-

clang/docs/analyzer/developer-docs/DebugChecks.rst

- ``clang_analyzer_dumpElementCount(a single argument of any type)``
 
   Example usage::
 
     void array() {
       int a[] = {1, 3};
       clang_analyzer_dumpExtent(a);       // expected-warning {{8 S64b}}
       clang_analyzer_dumpElementCount(a); // expected-warning {{2 S64b}}
     }
-    
 - ``clang_analyzer_value(a single argument of integer or pointer type)``
 
   Prints an associated value for the given argument.
   Supported argument types are integers, enums and pointers.
   The value can be represented either as a range set or as a concrete integer.
   For the rest of the types function prints ``n/a`` (aka not available).
-  
   **Note:** This function will print nothing for clang built with Z3 constraint manager.
   This may cause crashes of your tests. To manage this use one of the test constraining
   techniques:
-  
   * llvm-lit commands ``REQUIRES no-z3`` or ``UNSUPPORTED z3`` `See for details. <https://llvm.org/docs/TestingGuide.html#constraining-test-execution>`_
-  
   * a preprocessor directive ``#ifndef ANALYZER_CM_Z3``
-  
   * a clang command argument ``-analyzer-constraints=range``
 
   Example usage::
 
     void print(char c, unsigned u) {
       clang_analyzer_value(c); // expected-warning {{8s:{ [-128, 127] }}}
       if(u != 42)
          clang_analyzer_value(u); // expected-warning {{32u:{ [0, 41], [43, 4294967295] }}}

clang/docs/tools/dump_ast_matchers.py

"""
         if m:
             name = m.groups()[0]
             add_matcher("*", name, "Matcher<*>...Matcher<*>", comment)
             return
 
         # Parse free standing matcher functions, like:
         #   Matcher<ResultType> Name(Matcher<ArgumentType> InnerMatcher) {
         m = re.match(
-            r"""^\s*(?:template\s+<\s*(?:class|typename)\s+(.+)\s*>\s+)?   
+            r"""^\s*(?:template\s+<\s*(?:class|typename)\s+(.+)\s*>\s+)?
                      (.*)\s+
                      ([^\s\(]+)\s*\(
                      (.*)
                      \)\s*{""",
             declaration,
             re.X,
         )
         if m:

clang/include/clang/AST/DeclCXX.h

public:
   }
 
   /// Determine whether this is a structural type.
   bool isStructural() const {
     return isLiteral() && data().StructuralIfLiteral;
   }
 
   /// Notify the class that this destructor is now selected.
-  /// 
+  ///
   /// Important properties of the class depend on destructor properties. Since
   /// C++20, it is possible to have multiple destructor declarations in a class
   /// out of which one will be selected at the end.
   /// This is called separately from addedMember because it has to be deferred
   /// to the completion of the class.
   void addedSelectedDestructor(CXXDestructorDecl *DD);
 
   /// Notify the class that an eligible SMF has been added.

clang/include/clang/AST/DeclObjC.h

private:
   /// CmdDecl - Decl for the implicit _cmd parameter. This is lazily
   /// constructed by createImplicitParams.
   ImplicitParamDecl *CmdDecl = nullptr;
 
   ObjCMethodDecl(SourceLocation beginLoc, SourceLocation endLoc,
                  Selector SelInfo, QualType T, TypeSourceInfo *ReturnTInfo,
                  DeclContext *contextDecl, bool isInstance = true,
                  bool isVariadic = false, bool isPropertyAccessor = false,
-                 bool isSynthesizedAccessorStub = false, 
+                 bool isSynthesizedAccessorStub = false,
                  bool isImplicitlyDeclared = false, bool isDefined = false,
                  ImplementationControl impControl = None,
                  bool HasRelatedResultType = false);
 
   SelectorLocationsKind getSelLocsKind() const {
     return static_cast<SelectorLocationsKind>(ObjCMethodDeclBits.SelLocsKind);
   }
 

clang/include/clang/AST/TypeProperties.td

 //==--- TypeProperties.td - Type property definitions ---------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 include "clang/AST/PropertiesBase.td"
 include "clang/Basic/TypeNodes.td"
 
 let Class = ComplexType in {
   def : Property<"elementType", QualType> {
-    let Read = [{ node->getElementType() }];    
+    let Read = [{ node->getElementType() }];
   }
 
   def : Creator<[{ return ctx.getComplexType(elementType); }]>;
 }
 
 let Class = PointerType in {
   def : Property<"pointeeType", QualType> {
     let Read = [{ node->getPointeeType() }];

 
 let Class = ParenType in {
   def : Property<"innerType", QualType> {
     let Read = [{ node->getInnerType() }];
   }
 
   def : Creator<[{
     return ctx.getParenType(innerType);
-  }]>;  
+  }]>;
 }
 
 let Class = MacroQualifiedType in {
   def : Property<"underlyingType", QualType> {
     let Read = [{ node->getUnderlyingType() }];
   }
   def : Property<"macroIdentifier", Identifier> {
     let Read = [{ node->getMacroIdentifier() }];
def : Creator<[{
     return ctx.getObjCInterfaceType(
              cast<ObjCInterfaceDecl>(declaration->getCanonicalDecl()));
   }]>;
 }
 
 let Class = ObjCTypeParamType in {
   def : Property<"declaration", ObjCTypeParamDeclRef> {
     let Read = [{ node->getDecl() }];
-  }  
+  }
   def : Property<"qualifiers", Array<ObjCProtocolDeclRef>> {
     let Read = [{ node->getProtocols() }];
   }
 
   def : Creator<[{
     return ctx.getObjCTypeParamType(declaration, qualifiers);
   }]>;
 }

clang/include/clang/Analysis/AnalysisDeclContext.h

public:
 
   const CFGBlock *getCallSiteBlock() const { return Block; }
 
   bool inTopFrame() const override { return getParent() == nullptr; }
 
   unsigned getIndex() const { return Index; }
 
   CFGElement getCallSiteCFGElement() const { return (*Block)[Index]; }
-  
   void Profile(llvm::FoldingSetNodeID &ID) override;
 
   static void Profile(llvm::FoldingSetNodeID &ID, AnalysisDeclContext *ADC,
                       const LocationContext *ParentLC, const Stmt *S,
                       const CFGBlock *Block, unsigned BlockCount,
                       unsigned Index) {
     ProfileCommon(ID, StackFrame, ADC, ParentLC, S);
     ID.AddPointer(Block);

clang/include/clang/Analysis/CallGraph.h

public:
   /// Recursively walks the declaration to find all the dependent Decls as well.
   void addToCallGraph(Decl *D) {
     TraverseDecl(D);
   }
 
   /// Determine if a declaration should be included in the graph.
   static bool includeInGraph(const Decl *D);
 
-  /// Determine if a declaration should be included in the graph for the 
+  /// Determine if a declaration should be included in the graph for the
   /// purposes of being a callee. This is similar to includeInGraph except
   /// it permits declarations, not just definitions.
   static bool includeCalleeInGraph(const Decl *D);
 
   /// Lookup the node for the given declaration.
   CallGraphNode *getNode(const Decl *) const;
 
   /// Lookup the node for the given declaration. If none found, insert

clang/include/clang/Basic/AttrDocs.td

 migration for code using ``[[noreturn]]`` after including ``<stdnoreturn.h>``.
   }];
 }
 
 def NoMergeDocs : Documentation {
   let Category = DocCatStmt;
   let Content = [{
 If a statement is marked ``nomerge`` and contains call expressions, those call
-expressions inside the statement will not be merged during optimization. This 
+expressions inside the statement will not be merged during optimization. This
 attribute can be used to prevent the optimizer from obscuring the source
 location of certain calls. For example, it will prevent tail merging otherwise
 identical code sequences that raise an exception or terminate the program. Tail
 merging normally reduces the precision of source location information, making
 stack traces less useful for debugging. This attribute gives the user control
-over the tradeoff between code size and debug information precision. 
+over the tradeoff between code size and debug information precision.
 
-``nomerge`` attribute can also be used as function attribute to prevent all 
-calls to the specified function from merging. It has no effect on indirect 
+``nomerge`` attribute can also be used as function attribute to prevent all
+calls to the specified function from merging. It has no effect on indirect
 calls.
   }];
 }
 
 def NoInlineDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 This function attribute suppresses the inlining of a function at the call sites

 
 ``tvos``
   Apple's tvOS operating system. The minimum deployment target is specified by
   the ``-mtvos-version-min=*version*`` command-line argument.
 
 ``watchos``
   Apple's watchOS operating system. The minimum deployment target is specified by
   the ``-mwatchos-version-min=*version*`` command-line argument.
-  
 ``driverkit``
   Apple's DriverKit userspace kernel extensions. The minimum deployment target
   is specified as part of the triple.
 
 A declaration can typically be used even when deploying back to a platform
 version prior to when the declaration was introduced. When this happens, the
 declaration is `weakly linked
 <https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,

 
 
 def NullabilityDocs : DocumentationCategory<"Nullability Attributes"> {
   let Content = [{
 Whether a particular pointer may be "null" is an important concern when working
 with pointers in the C family of languages. The various nullability attributes
 indicate whether a particular pointer can be null or not, which makes APIs more
 expressive and can help static analysis tools identify bugs involving null
-pointers. Clang supports several kinds of nullability attributes: the 
+pointers. Clang supports several kinds of nullability attributes: the
 ``nonnull`` and ``returns_nonnull`` attributes indicate which function or
 method parameters and result types can never be null, while nullability type
 qualifiers indicate which pointer types can be null (``_Nullable``) or cannot
 be null (``_Nonnull``).
 
 The nullability (type) qualifiers express whether a value of a given pointer
 type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning
 for null (the ``_Nonnull`` qualifier), or for which the purpose of null is
memory is not available rather than returning a null pointer:
 
   .. code-block:: c
 
     extern void * malloc (size_t size) __attribute__((returns_nonnull));
 
 The ``returns_nonnull`` attribute implies that returning a null pointer is
 undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
 type qualifier indicates that a pointer cannot be null in a more general manner
-(because it is part of the type system) and does not imply undefined behavior, 
+(because it is part of the type system) and does not imply undefined behavior,
 making it more widely applicable
 }];
 }
 
 def NoAliasDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``noalias`` attribute indicates that the only memory accesses inside

 }];
 }
 
 def CFGuardDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 Code can indicate CFG checks are not wanted with the ``__declspec(guard(nocf))``
 attribute. This directs the compiler to not insert any CFG checks for the entire
-function. This approach is typically used only sparingly in specific situations 
-where the programmer has manually inserted "CFG-equivalent" protection. The 
-programmer knows that they are calling through some read-only function table 
-whose address is obtained through read-only memory references and for which the 
-index is masked to the function table limit. This approach may also be applied 
-to small wrapper functions that are not inlined and that do nothing more than 
-make a call through a function pointer. Since incorrect usage of this directive 
-can compromise the security of CFG, the programmer must be very careful using 
-the directive. Typically, this usage is limited to very small functions that 
+function. This approach is typically used only sparingly in specific situations
+where the programmer has manually inserted "CFG-equivalent" protection. The
+programmer knows that they are calling through some read-only function table
+whose address is obtained through read-only memory references and for which the
+index is masked to the function table limit. This approach may also be applied
+to small wrapper functions that are not inlined and that do nothing more than
+make a call through a function pointer. Since incorrect usage of this directive
+can compromise the security of CFG, the programmer must be very careful using
+the directive. Typically, this usage is limited to very small functions that
 only call one function.
 
 `Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`
 }];
 }
 
 def CUDADeviceBuiltinSurfaceTypeDocs : Documentation {
   let Category = DocCatType;
def ReadOnlyPlacementDocs : Documentation {
   5. A type ``Q`` inherits from type ``T`` and it does not have the
      ``enforce_read_only_placement`` attribute.
   }];
 }
 
 def WebAssemblyFuncrefDocs : Documentation {
   let Category = DocCatType;
   let Content = [{
-Clang supports the ``__funcref`` attribute for the WebAssembly target. 
-This attribute may be attached to a function pointer type, where it modifies 
+Clang supports the ``__funcref`` attribute for the WebAssembly target.
+This attribute may be attached to a function pointer type, where it modifies
 its underlying representation to be a WebAssembly ``funcref``.
   }];
 }

clang/include/clang/Basic/DiagnosticGroups.td

  code Documentation = [{
 More fine grained information about the stack layout is available by adding the
 `-Rpass-analysis=stack-frame-layout` command-line flag to the compiler
 invocation.
 
 The diagnostic information can be saved to a file in a machine readable format,
 like YAML by adding the `-foptimization-record-file=<file>` command-line flag.
 
-Results can be filtered by function name by passing 
+Results can be filtered by function name by passing
 `-mllvm -filter-print-funcs=foo`, where `foo` is the target function's name.
 
    .. code-block: console
       clang -c a.cpp -Rpass-analysis=stack-frame-layout -mllvm -filter-print-funcs=foo
 
    .. code-block: console
       clang -c a.cpp -Rpass-analysis=stack-frame-layout -foptimization-record-file=<file>
 }];

clang/include/clang/Basic/DiagnosticParseKinds.td

def err_expected_member_name_or_semi_objcxx_keyword : Error<
   "%0 is a keyword in Objective-C++">;
 
 /// C++ parser diagnostics
 def err_invalid_operator_on_type : Error<
   "cannot use %select{dot|arrow}0 operator on a type">;
 def err_expected_unqualified_id : Error<
   "expected %select{identifier|unqualified-id}0">;
 def err_while_loop_outside_of_a_function : Error<
-  "while loop outside of a function">; 
+  "while loop outside of a function">;
 def err_brackets_go_after_unqualified_id : Error<
   "brackets are not allowed here; to declare an array, "
   "place the brackets after the %select{identifier|name}0">;
 def err_unexpected_unqualified_id : Error<"type-id cannot have a name">;
 def err_func_def_no_params : Error<
   "function definition does not declare parameters">;
 def err_expected_lparen_after_type : Error<
   "expected '(' for function-style cast or type construction">;

clang/include/clang/Basic/OpenCLExtensions.def

 //   core - OpenCL versions mask when the extension becomes core feature.
 //          0U indicates not a core feature.
 //   opt - OpenCL versions mask when the extension becomes optional core
 //         feature. 0U indicates not a optional core feature.
 //
 // If extensions are to be enumerated without any information,
 // define OPENCLEXTNAME(ext) where ext is the name of the extension.
 //
-// Difference between optional core feature and core feature is that the 
+// Difference between optional core feature and core feature is that the
 // later is unconditionally supported in specific OpenCL version.
 //
 // As per The OpenCL Extension Specification, Section 1.2, in this file, an
 // extension is defined if and only it either:
 //  * affects the OpenCL language semantics or its syntax,
 //  * adds built-in functions to the language.
 //
 // For such an extension, a preprocessor #define that matches the extension

clang/include/clang/Basic/TypeNodes.td

 include "clang/Basic/ASTNode.td"
 
 class TypeNode<TypeNode base, bit abstract = 0> : ASTNode {
   TypeNode Base = base;
   bit Abstract = abstract;
-} 
+}
 
 /// A type node that is only used to represent dependent types in C++.  For
 /// example, DependentTemplateSpecializationType is used to represent types
 /// where the base template-id is dependent (such as `T::foo<U>`).  Code
 /// that only works with non-dependent types can ignore these type nodes.
 class AlwaysDependent {}
 
 /// A type node that is never used to represent a canonical type, which is to

clang/include/clang/Basic/riscv_vector.td

let Name = NAME,
         if (IsMasked) {
           std::rotate(Ops.begin(), Ops.begin() + 1, Ops.end() - 1);
           if ((PolicyAttrs & RVV_VTA) && (PolicyAttrs & RVV_VMA))
             Ops.insert(Ops.begin(), llvm::PoisonValue::get(ResultType));
         } else {
           if (PolicyAttrs & RVV_VTA)
             Ops.insert(Ops.begin(), llvm::PoisonValue::get(ResultType));
         }
-        Ops.insert(Ops.begin() + 2, llvm::Constant::getNullValue(Ops.back()->getType())); 
+        Ops.insert(Ops.begin() + 2, llvm::Constant::getNullValue(Ops.back()->getType()));
         if (IsMasked) {
           Ops.push_back(ConstantInt::get(Ops.back()->getType(), PolicyAttrs));
           // maskedoff, op1, xlen, mask, vl
           IntrinsicTypes = {ResultType,
                             Ops[1]->getType(),
                             Ops[4]->getType(),
                             Ops[4]->getType()};
         } else {

clang/include/clang/Driver/Options.td

 def mconsole : Joined<["-"], "mconsole">, Group<m_Group>, Flags<[NoXarchOption]>;
 def mwindows : Joined<["-"], "mwindows">, Group<m_Group>, Flags<[NoXarchOption]>;
 def mdll : Joined<["-"], "mdll">, Group<m_Group>, Flags<[NoXarchOption]>;
 def municode : Joined<["-"], "municode">, Group<m_Group>, Flags<[NoXarchOption]>;
 def mthreads : Joined<["-"], "mthreads">, Group<m_Group>, Flags<[NoXarchOption]>;
 def mguard_EQ : Joined<["-"], "mguard=">, Group<m_Group>, Flags<[NoXarchOption]>,
   HelpText<"Enable or disable Control Flow Guard checks and guard tables emission">,
   Values<"none,cf,cf-nochecks">;
-def mcpu_EQ : Joined<["-"], "mcpu=">, Group<m_Group>, 
+def mcpu_EQ : Joined<["-"], "mcpu=">, Group<m_Group>,
   HelpText<"For a list of available CPUs for the target use '-mcpu=help'">;
 def mmcu_EQ : Joined<["-"], "mmcu=">, Group<m_Group>;
 def msim : Flag<["-"], "msim">, Group<m_Group>;
 def mdynamic_no_pic : Joined<["-"], "mdynamic-no-pic">, Group<m_Group>;
 def mfix_and_continue : Flag<["-"], "mfix-and-continue">, Group<clang_ignored_m_Group>;
 def mieee_fp : Flag<["-"], "mieee-fp">, Group<clang_ignored_m_Group>;
 def minline_all_stringops : Flag<["-"], "minline-all-stringops">, Group<clang_ignored_m_Group>;
 def mno_inline_all_stringops : Flag<["-"], "mno-inline-all-stringops">, Group<clang_ignored_m_Group>;

clang/include/clang/Sema/CMakeLists.txt

 clang_tablegen(AttrTemplateInstantiate.inc -gen-clang-attr-template-instantiate
   -I ${CMAKE_CURRENT_SOURCE_DIR}/../../
   SOURCE ../Basic/Attr.td
   TARGET ClangAttrTemplateInstantiate)
-  
 clang_tablegen(AttrParsedAttrList.inc -gen-clang-attr-parsed-attr-list
   -I ${CMAKE_CURRENT_SOURCE_DIR}/../../
   SOURCE ../Basic/Attr.td
   TARGET ClangAttrParsedAttrList)
 
 clang_tablegen(AttrParsedAttrKinds.inc -gen-clang-attr-parsed-attr-kinds
   -I ${CMAKE_CURRENT_SOURCE_DIR}/../../
   SOURCE ../Basic/Attr.td

clang/include/clang/StaticAnalyzer/Checkers/Checkers.td

def CStringBufferOverlap : Checker<"BufferOverlap">,
   HelpText<"Checks for overlap in two buffer arguments">,
   Dependencies<[CStringModeling]>,
   Documentation<HasDocumentation>;
 
 def CStringNotNullTerm : Checker<"NotNullTerminated">,
   HelpText<"Check for arguments which are not null-terminating strings">,
   Dependencies<[CStringModeling]>,
   Documentation<HasDocumentation>;
- 
 def CStringUninitializedRead : Checker<"UninitializedRead">,
   HelpText<"Checks if the string manipulation function would read uninitialized bytes">,
   Dependencies<[CStringModeling]>,
   Documentation<HasDocumentation>;
-  
 } // end "alpha.unix.cstring"
 
 let ParentPackage = Unix in {
 
 def UnixAPIMisuseChecker : Checker<"API">,
   HelpText<"Check calls to various UNIX/Posix functions">,
   Documentation<HasDocumentation>;
 

clang/lib/Analysis/FlowSensitive/CMakeLists.txt

add_clang_library(clangAnalysisFlowSensitive
   clangAST
   clangBasic
   clangLex
   )
 
 add_subdirectory(Models)
 
 add_custom_command(OUTPUT HTMLLogger.inc
-  COMMAND "${Python3_EXECUTABLE}" ${CLANG_SOURCE_DIR}/utils/bundle_resources.py 
+  COMMAND "${Python3_EXECUTABLE}" ${CLANG_SOURCE_DIR}/utils/bundle_resources.py
   ${CMAKE_CURRENT_BINARY_DIR}/HTMLLogger.inc
   HTMLLogger.html HTMLLogger.css HTMLLogger.js
   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
   COMMENT "Bundling HTMLLogger resources"
   DEPENDS ${CLANG_SOURCE_DIR}/utils/bundle_resources.py HTMLLogger.html HTMLLogger.css HTMLLogger.js
   VERBATIM)
 add_custom_target(clangAnalysisFlowSensitiveResources DEPENDS HTMLLogger.inc)

clang/lib/Analysis/UninitializedValues.cpp

void handleUseOfUninitVariable(const VarDecl *vd,
     hadAnyUse = true;
   }
 
   void handleConstRefUseOfUninitVariable(const VarDecl *vd,
                                          const UninitUse &use) override {
     hadUse[currentBlock] = true;
     hadAnyUse = true;
   }
-  
   /// Called when the uninitialized variable analysis detects the
   /// idiom 'int x = x'.  All other uses of 'x' within the initializer
   /// are handled by handleUseOfUninitVariable.
   void handleSelfInit(const VarDecl *vd) override {
     hadUse[currentBlock] = true;
     hadAnyUse = true;
   }
 };

clang/lib/Analysis/UnsafeBufferUsage.cpp

 
 AST_MATCHER_P(CastExpr, castSubExpr, internal::Matcher<Expr>, innerMatcher) {
   return innerMatcher.matches(*Node.getSubExpr(), Finder, Builder);
 }
 
 // Matches a `UnaryOperator` whose operator is pre-increment:
 AST_MATCHER(UnaryOperator, isPreInc) {
   return Node.getOpcode() == UnaryOperator::Opcode::UO_PreInc;
-}  
+}
 
 // Returns a matcher that matches any expression 'e' such that `innerMatcher`
 // matches 'e' and 'e' is in an Unspecified Lvalue Context.
 static auto isInUnspecifiedLvalueContext(internal::Matcher<Expr> innerMatcher) {
   // clang-format off
   return
     expr(anyOf(
       implicitCastExpr(
public:
   bool isWarningGadget() const final { return false; }
 
   /// Returns a fixit that would fix the current gadget according to
   /// the current strategy. Returns std::nullopt if the fix cannot be produced;
   /// returns an empty list if no fixes are necessary.
   virtual std::optional<FixItList> getFixits(const Strategy &) const {
     return std::nullopt;
   }
-  
   /// Returns a list of two elements where the first element is the LHS of a pointer assignment
   /// statement and the second element is the RHS. This two-element list represents the fact that
   /// the LHS buffer gets its bounds information from the RHS buffer. This information will be used
   /// later to group all those variables whose types must be modified together to prevent type
   /// mismatches.
   virtual std::optional<std::pair<const VarDecl *, const VarDecl *>>
   getStrategyImplications() const {
     return std::nullopt;
public:
   static Matcher matcher() {
     auto PtrAssignExpr = binaryOperator(allOf(hasOperatorName("="),
       hasRHS(ignoringParenImpCasts(declRefExpr(hasPointerType(),
                                                to(varDecl())).
                                    bind(PointerAssignRHSTag))),
                                    hasLHS(declRefExpr(hasPointerType(),
                                                       to(varDecl())).
                                           bind(PointerAssignLHSTag))));
-    
     //FIXME: Handle declarations at assignments
     return stmt(isInUnspecifiedUntypedContext(PtrAssignExpr));
   }
-  
   virtual std::optional<FixItList> getFixits(const Strategy &S) const override;
 
   virtual const Stmt *getBaseStmt() const override { return PA; }
 
   virtual DeclUseList getClaimedVarUseSites() const override {
     return DeclUseList{PtrLHS, PtrRHS};
   }
 
for (const auto &F : Fixables) {
                            CorrectFixes.end());
       }
     }
 
     if (ImpossibleToFix) {
       FixItsForVariable.erase(VD);
       continue;
     }
-    
     const auto VarGroupForVD = VarGrpMap.find(VD);
     if (VarGroupForVD != VarGrpMap.end()) {
       for (const VarDecl * V : VarGroupForVD->second) {
         if (V == VD) {
           continue;
         }
         if (impossibleToFixForVar(FixablesForUnsafeVars, S, V)) {
           ImpossibleToFix = true;
for (const auto &[VD, Fixables] : FixablesForUnsafeVars.byVar) {
     // Fix-it shall not overlap with macros or/and templates:
     if (overlapWithMacro(FixItsForVariable[VD]) ||
         clang::internal::anyConflict(FixItsForVariable[VD],
                                      Ctx.getSourceManager())) {
       FixItsForVariable.erase(VD);
       continue;
     }
   }
-  
   for (auto VD : FixItsForVariable) {
     const auto VarGroupForVD = VarGrpMap.find(VD.first);
     const Strategy::Kind ReplacementTypeForVD = S.lookup(VD.first);
     if (VarGroupForVD != VarGrpMap.end()) {
       for (const VarDecl * Var : VarGroupForVD->second) {
         if (Var == VD.first) {
           continue;
         }
-        
         FixItList GroupFix;
         if (FixItsForVariable.find(Var) == FixItsForVariable.end()) {
           GroupFix = fixVariable(Var, ReplacementTypeForVD, Tracker,
                                            Var->getASTContext(), Handler);
         } else {
           GroupFix = FixItsForVariable[Var];
         }
-        
         for (auto Fix : GroupFix) {
           FixItsForVariable[VD.first].push_back(Fix);
         }
       }
     }
   }
   return FixItsForVariable;
 }
for (auto it = FixablesForAllVars.byVar.cbegin();
     } else {
       ++it;
     }
   }
 
   llvm::SmallVector<const VarDecl *, 16> UnsafeVars;
   for (const auto &[VD, ignore] : FixablesForAllVars.byVar)
     UnsafeVars.push_back(VD);
-  
   // Fixpoint iteration for pointer assignments
   using DepMapTy = DenseMap<const VarDecl *, std::set<const VarDecl *>>;
   DepMapTy DependenciesMap{};
   DepMapTy PtrAssignmentGraph{};
-    
   for (auto it : FixablesForAllVars.byVar) {
     for (const FixableGadget *fixable : it.second) {
       std::optional<std::pair<const VarDecl *, const VarDecl *>> ImplPair =
                                   fixable->getStrategyImplications();
       if (ImplPair) {
         std::pair<const VarDecl *, const VarDecl *> Impl = ImplPair.value();
         PtrAssignmentGraph[Impl.first].insert(Impl.second);
       }
     }
   }
-    
   /*
    The following code does a BFS traversal of the `PtrAssignmentGraph`
    considering all unsafe vars as starting nodes and constructs an undirected
    graph `DependenciesMap`. Constructing the `DependenciesMap` in this manner
    elimiates all variables that are unreachable from any unsafe var. In other
    words, this removes all dependencies that don't include any unsafe variable
    and consequently don't need any fixit generation.
    Note: A careful reader would observe that the code traverses
    `PtrAssignmentGraph` using `CurrentVar` but adds edges between `Var` and
    `Adj` and not between `CurrentVar` and `Adj`. Both approaches would
    achieve the same result but the one used here dramatically cuts the
    amount of hoops the second part of the algorithm needs to jump, given that
    a lot of these connections become "direct". The reader is advised not to
    imagine how the graph is transformed because of using `Var` instead of
    `CurrentVar`. The reader can continue reading as if `CurrentVar` was used,
    and think about why it's equivalent later.
    */
   std::set<const VarDecl *> VisitedVarsDirected{};
   for (const auto &[Var, ignore] : UnsafeOps.byVar) {
     if (VisitedVarsDirected.find(Var) == VisitedVarsDirected.end()) {
-  
       std::queue<const VarDecl*> QueueDirected{};
       QueueDirected.push(Var);
       while(!QueueDirected.empty()) {
         const VarDecl* CurrentVar = QueueDirected.front();
         QueueDirected.pop();
         VisitedVarsDirected.insert(CurrentVar);
         auto AdjacentNodes = PtrAssignmentGraph[CurrentVar];
         for (const VarDecl *Adj : AdjacentNodes) {
           if (VisitedVarsDirected.find(Adj) == VisitedVarsDirected.end()) {
             QueueDirected.push(Adj);
           }
           DependenciesMap[Var].insert(Adj);
           DependenciesMap[Adj].insert(Var);
         }
       }
     }
   }
-  
   // Group Connected Components for Unsafe Vars
   // (Dependencies based on pointer assignments)
   std::set<const VarDecl *> VisitedVars{};
   for (const auto &[Var, ignore] : UnsafeOps.byVar) {
     if (VisitedVars.find(Var) == VisitedVars.end()) {
       std::vector<const VarDecl *> VarGroup{};
-  
       std::queue<const VarDecl*> Queue{};
       Queue.push(Var);
       while(!Queue.empty()) {
         const VarDecl* CurrentVar = Queue.front();
         Queue.pop();
         VisitedVars.insert(CurrentVar);
         VarGroup.push_back(CurrentVar);
         auto AdjacentNodes = DependenciesMap[CurrentVar];

clang/lib/Basic/Targets/PPC.cpp

 };
 
 ArrayRef<TargetInfo::GCCRegAlias> PPCTargetInfo::getGCCRegAliases() const {
   return llvm::ArrayRef(GCCRegAliases);
 }
 
 // PPC ELFABIv2 DWARF Definitoin "Table 2.26. Mappings of Common Registers".
 // vs0 ~ vs31 is mapping to 32 - 63,
-// vs32 ~ vs63 is mapping to 77 - 108. 
+// vs32 ~ vs63 is mapping to 77 - 108.
 const TargetInfo::AddlRegName GCCAddlRegNames[] = {
     // Table of additional register names to use in user input.
-    {{"vs0"}, 32},   {{"vs1"}, 33},   {{"vs2"}, 34},   {{"vs3"}, 35}, 
+    {{"vs0"}, 32},   {{"vs1"}, 33},   {{"vs2"}, 34},   {{"vs3"}, 35},
     {{"vs4"}, 36},   {{"vs5"}, 37},   {{"vs6"}, 38},   {{"vs7"}, 39},
     {{"vs8"}, 40},   {{"vs9"}, 41},   {{"vs10"}, 42},  {{"vs11"}, 43},
     {{"vs12"}, 44},  {{"vs13"}, 45},  {{"vs14"}, 46},  {{"vs15"}, 47},
     {{"vs16"}, 48},  {{"vs17"}, 49},  {{"vs18"}, 50},  {{"vs19"}, 51},
     {{"vs20"}, 52},  {{"vs21"}, 53},  {{"vs22"}, 54},  {{"vs23"}, 55},
     {{"vs24"}, 56},  {{"vs25"}, 57},  {{"vs26"}, 58},  {{"vs27"}, 59},
     {{"vs28"}, 60},  {{"vs29"}, 61},  {{"vs30"}, 62},  {{"vs31"}, 63},
     {{"vs32"}, 77},  {{"vs33"}, 78},  {{"vs34"}, 79},  {{"vs35"}, 80},
     {{"vs36"}, 81},  {{"vs37"}, 82},  {{"vs38"}, 83},  {{"vs39"}, 84},
     {{"vs40"}, 85},  {{"vs41"}, 86},  {{"vs42"}, 87},  {{"vs43"}, 88},
     {{"vs44"}, 89},  {{"vs45"}, 90},  {{"vs46"}, 91},  {{"vs47"}, 92},
     {{"vs48"}, 93},  {{"vs49"}, 94},  {{"vs50"}, 95},  {{"vs51"}, 96},
     {{"vs52"}, 97},  {{"vs53"}, 98},  {{"vs54"}, 99},  {{"vs55"}, 100},
     {{"vs56"}, 101}, {{"vs57"}, 102}, {{"vs58"}, 103}, {{"vs59"}, 104},
     {{"vs60"}, 105}, {{"vs61"}, 106}, {{"vs62"}, 107}, {{"vs63"}, 108},
 };
 
 ArrayRef<TargetInfo::AddlRegName> PPCTargetInfo::getGCCAddlRegNames() const {
   if (ABI == "elfv2")
     return llvm::ArrayRef(GCCAddlRegNames);
-  else 
-    return TargetInfo::getGCCAddlRegNames(); 
+  else
+    return TargetInfo::getGCCAddlRegNames();
 }
 
 static constexpr llvm::StringLiteral ValidCPUNames[] = {
     {"generic"},     {"440"},     {"450"},    {"601"},       {"602"},
     {"603"},         {"603e"},    {"603ev"},  {"604"},       {"604e"},
     {"620"},         {"630"},     {"g3"},     {"7400"},      {"g4"},
     {"7450"},        {"g4+"},     {"750"},    {"8548"},      {"970"},
     {"g5"},          {"a2"},      {"e500"},   {"e500mc"},    {"e5500"},

clang/lib/CodeGen/CGBuiltin.cpp

if (FD->hasAttr<ConstAttr>() ||
     case Builtin::BI__builtin_roundeven:
     case Builtin::BI__builtin_roundevenf:
     case Builtin::BI__builtin_roundevenf16:
     case Builtin::BI__builtin_roundevenl:
     case Builtin::BI__builtin_roundevenf128:
       return RValue::get(emitUnaryMaybeConstrainedFPBuiltin(*this, E,
                                    Intrinsic::roundeven,
                                    Intrinsic::experimental_constrained_roundeven));
-                                   
     case Builtin::BIsin:
     case Builtin::BIsinf:
     case Builtin::BIsinl:
     case Builtin::BI__builtin_sin:
     case Builtin::BI__builtin_sinf:
     case Builtin::BI__builtin_sinf16:
     case Builtin::BI__builtin_sinl:
     case Builtin::BI__builtin_sinf128:

clang/lib/Driver/ToolChains/Clang.cpp

void Clang::AddPreprocessingOptions(Compilation &C, const JobAction &JA,
   // with ones created by the 'libc' project if present.
   if (!Args.hasArg(options::OPT_nostdinc) &&
       !Args.hasArg(options::OPT_nogpuinc) &&
       !Args.hasArg(options::OPT_nobuiltininc) &&
       (getToolChain().getTriple().isNVPTX() ||
        getToolChain().getTriple().isAMDGCN())) {
 
       // Add include/gpu-none-libc/* to our system include path. This lets us use
-      // GPU-specific system headers first. 
+      // GPU-specific system headers first.
       // TODO: We need to find a way to make these headers compatible with the
       // host environment.
       SmallString<128> P(llvm::sys::path::parent_path(D.InstalledDir));
       llvm::sys::path::append(P, "include");
       llvm::sys::path::append(P, "gpu-none-llvm");
       CmdArgs.push_back("-c-isystem");
       CmdArgs.push_back(Args.MakeArgString(P));
   }

clang/lib/Headers/CMakeLists.txt

install(
   EXCLUDE_FROM_ALL
   COMPONENT riscv-resource-headers)
 
 install(
   FILES ${riscv_files}
   DESTINATION ${header_install_dir}
   EXCLUDE_FROM_ALL
   COMPONENT riscv-resource-headers)
-  
 install(
   FILES ${systemz_files}
   DESTINATION ${header_install_dir}
   EXCLUDE_FROM_ALL
   COMPONENT systemz-resource-headers)
 
 install(
   FILES ${ve_files}

clang/lib/Sema/AnalysisBasedWarnings.cpp

void handleUnsafeVariableGroup(const VarDecl *Variable,
     S.Diag(Variable->getLocation(), diag::warn_unsafe_buffer_variable)
         << Variable << (Variable->getType()->isPointerType() ? 0 : 1)
         << Variable->getSourceRange();
     if (!Fixes.empty()) {
       const auto VarGroupForVD = VarGrpMap.find(Variable)->second;
       unsigned FixItStrategy = 0; // For now we only have 'std::span' strategy
       const auto &FD = S.Diag(Variable->getLocation(),
                               diag::note_unsafe_buffer_variable_fixit_group);
-      
       FD << Variable << FixItStrategy;
       std::string AllVars = "";
       if (VarGroupForVD.size() > 1) {
         if (VarGroupForVD.size() == 2) {
           if (VarGroupForVD[0] == Variable) {
             AllVars.append("'" + VarGroupForVD[1]->getName().str() + "'");
           } else {
             AllVars.append("'" + VarGroupForVD[0]->getName().str() + "'");

clang/lib/Sema/SemaDeclAttr.cpp

 
 /// Handle __attribute__((init_priority(priority))) attributes based on
 /// http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
 static void handleInitPriorityAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (!S.getLangOpts().CPlusPlus) {
     S.Diag(AL.getLoc(), diag::warn_attribute_ignored) << AL;
     return;
   }
-  
   if (S.getLangOpts().HLSL) {
     S.Diag(AL.getLoc(), diag::err_hlsl_init_priority_unsupported);
     return;
   }
 
   if (S.getCurFunctionOrMethodDecl()) {
     S.Diag(AL.getLoc(), diag::err_init_priority_object_attr);
     AL.setInvalid();

clang/lib/Sema/SemaOverload.cpp

case OR_Success: {
             Diag(OpLoc, diag::ext_ovl_ambiguous_oper_binary_reversed)
                 << BinaryOperator::getOpcodeStr(Opc)
                 << Args[0]->getType() << Args[1]->getType() << AmbiguousWithSelf
                 << Args[0]->getSourceRange() << Args[1]->getSourceRange();
             if (AmbiguousWithSelf) {
               Diag(FnDecl->getLocation(),
                    diag::note_ovl_ambiguous_oper_binary_reversed_self);
               // Mark member== const or provide matching != to disallow reversed
-              // args. Eg. 
-              // struct S { bool operator==(const S&); }; 
+              // args. Eg.
+              // struct S { bool operator==(const S&); };
               // S()==S();
               if (auto *MD = dyn_cast<CXXMethodDecl>(FnDecl))
                 if (Op == OverloadedOperatorKind::OO_EqualEqual &&
                     !MD->isConst() &&
                     Context.hasSameUnqualifiedType(
                         MD->getThisObjectType(),
                         MD->getParamDecl(0)->getType().getNonReferenceType()) &&
                     Context.hasSameUnqualifiedType(MD->getThisObjectType(),

clang/lib/Sema/SemaTemplateDeduction.cpp

Sema::TemplateDeductionResult Sema::FinishTemplateArgumentDeduction(
   Info.reset(SugaredDeducedArgumentList, CanonicalDeducedArgumentList);
 
   // Substitute the deduced template arguments into the function template
   // declaration to produce the function template specialization.
   DeclContext *Owner = FunctionTemplate->getDeclContext();
   if (FunctionTemplate->getFriendObjectKind())
     Owner = FunctionTemplate->getLexicalDeclContext();
   FunctionDecl *FD = FunctionTemplate->getTemplatedDecl();
-  // additional check for inline friend, 
+  // additional check for inline friend,
   // ```
   //   template <class F1> int foo(F1 X);
   //   template <int A1> struct A {
   //     template <class F1> friend int foo(F1 X) { return A1; }
   //   };
   //   template struct A<1>;
   //   int a = foo(1.0);
   // ```

clang/lib/Serialization/ASTReaderStmt.cpp

while (true) {
 
     case STMT_OMP_MASTER_TASKLOOP_DIRECTIVE: {
       unsigned CollapsedNum = Record[ASTStmtReader::NumStmtFields];
       unsigned NumClauses = Record[ASTStmtReader::NumStmtFields + 1];
       S = OMPMasterTaskLoopDirective::CreateEmpty(Context, NumClauses,
                                                   CollapsedNum, Empty);
       break;
     }
-    
     case STMT_OMP_MASKED_TASKLOOP_DIRECTIVE: {
       unsigned CollapsedNum = Record[ASTStmtReader::NumStmtFields];
       unsigned NumClauses = Record[ASTStmtReader::NumStmtFields + 1];
       S = OMPMaskedTaskLoopDirective::CreateEmpty(Context, NumClauses,
                                                   CollapsedNum, Empty);
       break;
     }
 

clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp

for (const auto &Cont : ContMap) {
     }
   }
 }
 
 void ContainerModeling::checkDeadSymbols(SymbolReaper &SR,
                                          CheckerContext &C) const {
   // Cleanup
   auto State = C.getState();
-  
   auto ContMap = State->get<ContainerMap>();
   for (const auto &Cont : ContMap) {
     if (!SR.isLiveRegion(Cont.first)) {
       // We must keep the container data while it has live iterators to be able
       // to compare them to the begin and the end of the container.
       if (!hasLiveIterators(State, Cont.first)) {
         State = State->remove<ContainerMap>(Cont.first);
       }

 // This function rebases symbolic expression `OldExpr + Int` to `NewExpr + Int`,
 // `OldExpr - Int` to `NewExpr - Int` and  `OldExpr` to `NewExpr` in expression
 // `OrigExpr`.
 SymbolRef rebaseSymbol(ProgramStateRef State, SValBuilder &SVB,
                        SymbolRef OrigExpr, SymbolRef OldExpr,
                        SymbolRef NewSym) {
   auto &SymMgr = SVB.getSymbolManager();
   auto Diff = SVB.evalBinOpNN(State, BO_Sub, nonloc::SymbolVal(OrigExpr),
-                              nonloc::SymbolVal(OldExpr), 
+                              nonloc::SymbolVal(OldExpr),
                               SymMgr.getType(OrigExpr));
 
   const auto DiffInt = Diff.getAs<nonloc::ConcreteInt>();
   if (!DiffInt)
     return OrigExpr;
 
   return SVB.evalBinOpNN(State, BO_Add, *DiffInt, nonloc::SymbolVal(NewSym),
                          SymMgr.getType(OrigExpr)).getAsSymbol();

clang/lib/StaticAnalyzer/Checkers/NSAutoreleasePoolChecker.cpp

void NSAutoreleasePoolChecker::checkPreObjCMessage(const ObjCMethodCall &msg,
   Report->addRange(msg.getSourceRange());
   C.emitReport(std::move(Report));
 }
 
 void ento::registerNSAutoreleasePoolChecker(CheckerManager &mgr) {
   mgr.registerChecker<NSAutoreleasePoolChecker>();
 }
 
-bool ento::shouldRegisterNSAutoreleasePoolChecker(const CheckerManager &mgr) { 
+bool ento::shouldRegisterNSAutoreleasePoolChecker(const CheckerManager &mgr) {
   const LangOptions &LO = mgr.getLangOpts();
   return LO.getGC() != LangOptions::NonGC;
 }

clang/lib/StaticAnalyzer/Core/ExprEngine.cpp

 }
 
 std::pair<ProgramStateRef, uint64_t>
 ExprEngine::prepareStateForArrayDestruction(const ProgramStateRef State,
                                             const MemRegion *Region,
                                             const QualType &ElementTy,
                                             const LocationContext *LCtx,
                                             SVal *ElementCountVal) {
-  assert(Region != nullptr && "Not-null region expected");  
+  assert(Region != nullptr && "Not-null region expected");
 
   QualType Ty = ElementTy.getDesugaredType(getContext());
   while (const auto *NTy = dyn_cast<ArrayType>(Ty))
     Ty = NTy->getElementType().getDesugaredType(getContext());
 
   auto ElementCount = getDynamicElementCount(State, Region, svalBuilder, Ty);
 
   if (ElementCountVal)

libcxx/utils/ci/buildkite-pipeline-clang.yml

 # which aims to test libc++ itself, this pipeline aims to test Clang by
 # compiling libc++ and running its test suite against the just-built Clang,
 # in various configurations.
 #
 env:
     # LLVM RELEASE bump version
     LLVM_HEAD_VERSION: "17"
 steps:
+  - label: "Format"
+    commands:
+      - "! grep -rn '[[:blank:]]$' clang/lib clang/include clang/docs || false"
+
+    agents:
+      queue: "libcxx-builders"
+      os: "linux"
+    retry:
+      automatic:
+        - exit_status: -1  # Agent was lost
+          limit: 2
+    timeout_in_minutes: 120
+
+  - wait
+
   - label: "Building clang"
     commands:
       - "mkdir install"
       # We use Release here to avoid including debug information. Otherwise, the clang binary is very large, which
       # is problematic because we need to upload the artifacts for other jobs to use. This may seem like nothing,
       # but with the number of jobs we run daily, this can result in thousands of GB of network I/O.
       - "cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install -DLLVM_ENABLE_PROJECTS=\"clang;compiler-rt\""
       - "ninja -C build install-clang install-clang-resource-headers"