[Docs] Fix Sphinx documentation formatting issues in LanguageExtensions.rst

[codemzs]

Summary

Fix indentation and spacing.

[codemzs]

Fix indentation and spacing.

Hi @pengfei and @rjmccall,

In the previous commit, the Sphinx documentation issues were overlooked due to an unexpected build error and the Sphinx build did not run as part of pre-build check. This was compounded by my unfamiliarity with the documentation generation process.

In this revision, I've addressed the indentation and spacing issues in the .rst files. The fixes have been validated locally using ninja docs-clang-html and ninja docs-llvm-html.

Apologies for the confusion in the previous submission. I look forward to your feedback on this revision.

[pengfei]

LGTM.

clang/docs/LanguageExtensions.rst

 in all language modes, but their support differs between targets.
 A target is said to have "native support" for a type if the target
 processor offers instructions for directly performing basic arithmetic
 on that type.  In the absence of native support, a type can still be
 supported if the compiler can emulate arithmetic on the type by promoting
 to ``float``; see below for more information on this emulation.
 
 * ``__fp16`` is supported on all targets. The special semantics of this
   type mean that no arithmetic is ever performed directly on ``__fp16`` values;
   see below.
 
 * ``_Float16`` is supported on the following targets:
   * 32-bit ARM (natively on some architecture versions)
   * 64-bit ARM (AArch64) (natively on ARMv8.2a and above)
   * AMDGPU (natively)
   * SPIR (natively)
   * X86 (if SSE2 is available; natively if AVX512-FP16 is also available)
 
 * ``__bf16`` is supported on the following targets (currently never natively):
   * 32-bit ARM
   * 64-bit ARM (AArch64)
   * X86 (when SSE2 is available)
 
 (For X86, SSE2 is available on 64-bit and all recent 32-bit processors.)
 
 ``__fp16`` and ``_Float16`` both use the binary16 format from IEEE
 754-2008, which provides a 5-bit exponent and an 11-bit significand
 (counting the implicit leading 1). ``__bf16`` uses the `bfloat16
 <https://en.wikipedia.org/wiki/Bfloat16_floating-point_format>`_ format,
 which provides an 8-bit exponent and an 8-bit significand; this is the same
 exponent range as `float`, just with greatly reduced precision.
 
 ``_Float16`` and ``__bf16`` follow the usual rules for arithmetic
-floating-point types.  Most importantly, this means that arithmetic operations
+floating-point types. Most importantly, this means that arithmetic operations
 on operands of these types are formally performed in the type and produce
 values of the type. ``__fp16`` does not follow those rules: most operations
 immediately promote operands of type ``__fp16`` to ``float``, and so
 arithmetic operations are defined to be performed in ``float`` and so result in
 a value of type ``float`` (unless further promoted because of other operands).
 See below for more information on the exact specifications of these types.
 
 When compiling arithmetic on ``_Float16`` and ``__bf16`` for a target without
 native support, Clang will perform the arithmetic in ``float``, inserting
 extensions and truncations as necessary. This can be done in a way that
 exactly matches the operation-by-operation behavior of native support,
 but that can require many extra truncations and extensions. By default,
 when emulating ``_Float16`` and ``__bf16`` arithmetic using ``float``, Clang
 does not truncate intermediate operands back to their true type unless the
 operand is the result of an explicit cast or assignment. This is generally
 much faster but can generate different results from strict operation-by-operation
 emulation. Usually the results are more precise. This is permitted by the
 C and C++ standards under the rules for excess precision in intermediate operands;
 see the discussion of evaluation formats in the C standard and [expr.pre] in
 the C++ standard.
 
 The use of excess precision can be independently controlled for these two
 types with the ``-ffloat16-excess-precision=`` and
-``-fbfloat16-excess-precision=`` options.  Valid values include:
-- ``none`` (meaning to perform strict operation-by-operation emulation)
-- ``standard`` (meaning that excess precision is permitted under the rules
-  described in the standard, i.e. never across explicit casts or statements)
-- ``fast`` (meaning that excess precision is permitted whenever the
+``-fbfloat16-excess-precision=`` options. Valid values include:
+
+* ``none``: meaning to perform strict operation-by-operation emulation
+* ``standard``: meaning that excess precision is permitted under the rules
+  described in the standard, i.e. never across explicit casts or statements
+* ``fast``: meaning that excess precision is permitted whenever the
   optimizer sees an opportunity to avoid truncations; currently this has no
-  effect beyond ``standard``)
+  effect beyond ``standard``
 
 The ``_Float16`` type is an interchange floating type specified in
- ISO/IEC TS 18661-3:2015 ("Floating-point extensions for C").  It will
+ISO/IEC TS 18661-3:2015 ("Floating-point extensions for C"). It will
 be supported on more targets as they define ABIs for it.
 
 The ``__bf16`` type is a non-standard extension, but it generally follows
 the rules for arithmetic interchange floating types from ISO/IEC TS
-18661-3:2015.  In previous versions of Clang, it was a storage-only type
-that forbade arithmetic operations.  It will be supported on more targets
+18661-3:2015. In previous versions of Clang, it was a storage-only type
+that forbade arithmetic operations. It will be supported on more targets
 as they define ABIs for it.
 
 The ``__fp16`` type was originally an ARM extension and is specified
 by the `ARM C Language Extensions <https://github.com/ARM-software/acle/releases>`_.
 Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``,
-not the ARM alternative format.  Operators that expect arithmetic operands
+not the ARM alternative format. Operators that expect arithmetic operands
 immediately promote ``__fp16`` operands to ``float``.
 
 It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
 as it has been defined by the C standards committee and has behavior that is
 more familiar to most programmers.
 
 Because ``__fp16`` operands are always immediately promoted to ``float``, the
 common real type of ``__fp16`` and ``_Float16`` for the purposes of the usual
 arithmetic conversions is ``float``.
 
 A literal can be given ``_Float16`` type using the suffix ``f16``. For example,
 ``3.14f16``.
 
 Because default argument promotion only applies to the standard floating-point
 types, ``_Float16`` values are not promoted to ``double`` when passed as variadic
-or untyped arguments.  As a consequence, some caution must be taken when using
+or untyped arguments. As a consequence, some caution must be taken when using
 certain library facilities with ``_Float16``; for example, there is no ``printf`` format
 specifier for ``_Float16``, and (unlike ``float``) it will not be implicitly promoted to
 ``double`` when passed to ``printf``, so the programmer must explicitly cast it to
 ``double`` before using it with an ``%f`` or similar specifier.
 
 Messages on ``deprecated`` and ``unavailable`` Attributes
 =========================================================