[clang] 347ab99 - [Clang][Docs] Fix trailing whitespace warnings

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2024-02-07T13:03:31-06:00
New Revision: 347ab99a5c6d096beb7378794c6255dca2a866e6

URL: https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6
DIFF: https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6.diff

LOG: [Clang][Docs] Fix trailing whitespace warnings

Added: 
    

Modified: 
    clang/docs/ClangLinkerWrapper.rst
    clang/docs/OffloadingDesign.rst

Removed: 
    


################################################################################
diff  --git a/clang/docs/ClangLinkerWrapper.rst b/clang/docs/ClangLinkerWrapper.rst
index 1e851b0aa0619..6d7770b50e726 100644
--- a/clang/docs/ClangLinkerWrapper.rst
+++ b/clang/docs/ClangLinkerWrapper.rst
@@ -64,19 +64,19 @@ only for the linker wrapper will be forwarded to the wrapped linker job.
 Relocatable Linking
 ===================
 
-The ``clang-linker-wrapper`` handles linking embedded device code and then 
-registering it with the appropriate runtime. Normally, this is only done when 
-the executable is created so other files containing device code can be linked 
-together. This can be somewhat problematic for users who wish to ship static 
-libraries that contain offloading code to users without a compatible offloading 
+The ``clang-linker-wrapper`` handles linking embedded device code and then
+registering it with the appropriate runtime. Normally, this is only done when
+the executable is created so other files containing device code can be linked
+together. This can be somewhat problematic for users who wish to ship static
+libraries that contain offloading code to users without a compatible offloading
 toolchain.
 
-When using a relocatable link with ``-r``, the ``clang-linker-wrapper`` will 
-perform the device linking and registration eagerly. This will remove the 
-embedded device code and register it correctly with the runtime. Semantically, 
-this is similar to creating a shared library object. If standard relocatable 
-linking is desired, simply do not run the binaries through the 
-``clang-linker-wrapper``. This will simply append the embedded device code so 
+When using a relocatable link with ``-r``, the ``clang-linker-wrapper`` will
+perform the device linking and registration eagerly. This will remove the
+embedded device code and register it correctly with the runtime. Semantically,
+this is similar to creating a shared library object. If standard relocatable
+linking is desired, simply do not run the binaries through the
+``clang-linker-wrapper``. This will simply append the embedded device code so
 that it can be linked later.
 
 Example

diff  --git a/clang/docs/OffloadingDesign.rst b/clang/docs/OffloadingDesign.rst
index 04319cd869b19..13bb924a77ad0 100644
--- a/clang/docs/OffloadingDesign.rst
+++ b/clang/docs/OffloadingDesign.rst
@@ -474,27 +474,27 @@ We can see the steps created by clang to generate the offloading code using the
 Relocatable Linking
 -------------------
 
-The offloading compilation pipeline normally will defer the final device linking 
-and runtime registration until the ``clang-linker-wrapper`` is run to create the 
-executable. This is the standard behaviour when compiling for OpenMP offloading 
-or CUDA and HIP in ``-fgpu-rdc`` mode. However, there are some cases where the 
-user may wish to perform this device handling prematurely. This is described in 
+The offloading compilation pipeline normally will defer the final device linking
+and runtime registration until the ``clang-linker-wrapper`` is run to create the
+executable. This is the standard behaviour when compiling for OpenMP offloading
+or CUDA and HIP in ``-fgpu-rdc`` mode. However, there are some cases where the
+user may wish to perform this device handling prematurely. This is described in
 the :doc:`linker wrapper documentation<ClangLinkerWrapper>`.
 
-Effectively, this allows the user to handle offloading specific linking ahead of 
-time when shipping objects or static libraries. This can be thought of as 
-performing a standard ``-fno-gpu-rdc`` compilation on a subset of object files. 
-This can be useful to reduce link time, prevent users from interacting with the 
+Effectively, this allows the user to handle offloading specific linking ahead of
+time when shipping objects or static libraries. This can be thought of as
+performing a standard ``-fno-gpu-rdc`` compilation on a subset of object files.
+This can be useful to reduce link time, prevent users from interacting with the
 library's device code, or for shipping libraries to incompatible compilers.
 
-Normally, if a relocatable link is done using ``clang -r`` it will simply merge 
-the ``.llvm.offloading`` sections which will then be linked later when the 
-executable is created. However, if the ``-r`` flag is used with the offloading 
-toolchain, it will perform the device linking and registration phases and then 
+Normally, if a relocatable link is done using ``clang -r`` it will simply merge
+the ``.llvm.offloading`` sections which will then be linked later when the
+executable is created. However, if the ``-r`` flag is used with the offloading
+toolchain, it will perform the device linking and registration phases and then
 merge the registration code into the final relocatable object file.
 
-The following example shows how using the relocatable link with the offloading 
-pipeline can create a static library with offloading code that can be 
+The following example shows how using the relocatable link with the offloading
+pipeline can create a static library with offloading code that can be
 redistributed without requiring any additional handling.
 
 .. code-block:: console