docs: Fix badly indented lists

docs/abi-spec.rst

@@ -78,6 +78,7 @@ The following (fixed-size) array type exists:
 - ``<type>[M]``: a fixed-length array of ``M`` elements, ``M >= 0``, of the given type.
 
   .. note::
+
       While this ABI specification can express fixed-length arrays with zero elements, they're not supported by the compiler.
 
 The following non-fixed-size types exist:
@@ -761,6 +762,7 @@ As an example, the encoding of ``int16(-1), bytes1(0x42), uint16(0x03), string("
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^ string("Hello, world!") without a length field
 
 More specifically:
+
 - During the encoding, everything is encoded in-place. This means that there is
   no distinction between head and tail, as in the ABI encoding, and the length
   of an array is not encoded.

docs/ir/ir-breaking-changes.rst

@@ -11,7 +11,7 @@ Semantic Only Changes
 This section lists the changes that are semantic-only, thus potentially
 hiding new and different behavior in existing code.
 
- * When storage structs are deleted, every storage slot that contains a member of the struct is set to zero entirely. Formally, padding space was left untouched.
+- When storage structs are deleted, every storage slot that contains a member of the struct is set to zero entirely. Formally, padding space was left untouched.
   Consequently, if the padding space within a struct is used to store data (e.g. in the context of a contract upgrade), you have to be aware that ``delete`` will now also clear the added member (while it wouldn't have been cleared in the past).
 
   .. code-block:: solidity
@@ -35,7 +35,7 @@ Consequently, if the padding space within a struct is used to store data (e.g. i
 
   We have the same behavior for implicit delete, for example when array of structs is shortened.
 
- * Function modifiers are implemented in a slightly different way regarding function parameters.
+- Function modifiers are implemented in a slightly different way regarding function parameters.
   This especially has an effect if the placeholder ``_;`` is evaluated multiple times in a modifier.
   In the old code generator, each function parameter has a fixed slot on the stack. If the function
   is run multiple times because ``_;`` is used multiple times or used in a loop, then a change to the
@@ -57,18 +57,21 @@ We have the same behavior for implicit delete, for example when array of structs
   If you execute ``f(0)`` in the old code generator, it will return ``2``, while
   it will return ``1`` when using the new code generator.
 
- * The order of contract initialization has changed in case of inheritance.
+- The order of contract initialization has changed in case of inheritance.
 
   The order used to be:
+
   - All state variables are zero-initialized at the beginning.
   - Evaluate base constructor arguments from most derived to most base contract.
   - Initialize all state variables in the whole inheritance hierarchy from most base to most derived.
   - Run the constructor, if present, for all contracts in the linearized hierarchy from most base to most derived.
 
   New order:
+
   - All state variables are zero-initialized at the beginning.
   - Evaluate base constructor arguments from most derived to most base contract.
   - For every contract in order from most base to most derived in the linearized hierarchy execute:
+
       1. If present at declaration, initial values are assigned to state variables.
       2. Constructor, if present.
 
@@ -95,7 +98,7 @@ This causes differences in some contracts, for example:
   Previously, ``y`` would be set to 0. This is due to the fact that we would first initialize state variables: First, ``x`` is set to 0, and when initializing ``y``, ``f()`` would return 0 causing ``y`` to be 0 as well.
   With the new rules, ``y`` will be set to 42. We first initialize ``x`` to 0, then call A's constructor which sets ``x`` to 42. Finally, when initializing ``y``, ``f()`` returns 42 causing ``y`` to be 42.
 
- * Copying ``bytes`` arrays from memory to storage is implemented in a different way. The old code generator always copies full words, while the new one cuts the byte array after its end. The old behaviour can lead to dirty data being copied after the end of the array (but still in the same storage slot).
+- Copying ``bytes`` arrays from memory to storage is implemented in a different way. The old code generator always copies full words, while the new one cuts the byte array after its end. The old behaviour can lead to dirty data being copied after the end of the array (but still in the same storage slot).
   This causes differences in some contracts, for example:
 
   .. code-block:: solidity
@@ -123,7 +126,7 @@ Now it is returning ``0x64656164626565660000000000000000000000000000000000000000
 
   .. index:: ! evaluation order; expression
 
-* For the old code generator, the evaluation order of expressions is unspecified.
+- For the old code generator, the evaluation order of expressions is unspecified.
   For the new code generator, we try to evaluate in source order (left to right), but do not guarantee it.
   This can lead to semantic differences.
 
@@ -140,6 +143,7 @@ For example:
       }
 
   The function ``preincr_u8(1)`` returns the following values:
+
   - Old code generator: 3 (``1 + 2``) but the return value is unspecified in general
   - New code generator: 4 (``2 + 2``) but the return value is not guaranteed
 
@@ -162,6 +166,7 @@ For example:
       }
 
   The function ``g(1, 2)`` returns the following values:
+
   - Old code generator: ``10`` (``add(2 + 3, 2 + 3)``) but the return value is unspecified in general
   - New code generator: ``10`` but the return value is not guaranteed
 
@@ -170,6 +175,7 @@ and left-to-right by the new code generator.
   For example:
 
   ::
+
       // SPDX-License-Identifier: GPL-3.0
       pragma solidity >0.8.0;
       contract C {
@@ -183,6 +189,7 @@ For example:
       }
 
   The function ``f()`` returns the following values:
+
   - Old code generator: ``aMod = 0`` and ``mMod = 2``
   - New code generator: ``aMod = 4`` and ``mMod = 0``
 
@@ -234,6 +241,7 @@ For example:
     }
 
 The function ``f(1)`` returns the following values:
+
 - Old code generator: (``fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe``, ``00000000000000000000000000000000000000000000000000000000000000fe``)
 - New code generator: (``00000000000000000000000000000000000000000000000000000000000000fe``, ``00000000000000000000000000000000000000000000000000000000000000fe``)
 

docs/yul.rst

@@ -985,6 +985,7 @@ that are not known to the Yul compiler. It also allows you to create
 bytecode sequences that will not be modified by the optimizer.
 
 The functions are ``verbatim_<n>i_<m>o("<data>", ...)``, where
+
 - ``n`` is a decimal between 0 and 99 that specifies the number of input stack slots / variables
 - ``m`` is a decimal between 0 and 99 that specifies the number of output stack slots / variables
 - ``data`` is a string literal that contains the sequence of bytes