[llvm-branch-commits] [llvm] [docs] Migrate 22 popular LLVM docs to MyST (PR #201244)

[Reid Kleckner via llvm-branch-commits]

================
@@ -2594,164 +2410,150 @@ larger counts are rare.
 At this time, SmallBitVector does not support set operations (and, or, xor), and
 its operator[] does not provide an assignable lvalue.
 
-.. _dss_sparsebitvector:
+(dss_sparsebitvector)=
 
-SparseBitVector
-^^^^^^^^^^^^^^^
+#### SparseBitVector
 
-The ``SparseBitVector`` container is much like ``BitVector``, with one major difference:
-Only the bits that are set, are stored.  This makes the ``SparseBitVector`` much
-more space efficient than ``BitVector`` when the set is sparse, as well as making
+The `SparseBitVector` container is much like `BitVector`, with one major difference:
+Only the bits that are set, are stored.  This makes the `SparseBitVector` much
+more space efficient than `BitVector` when the set is sparse, as well as making
 set operations O(number of set bits) instead of O(size of universe).  The
-downside to the ``SparseBitVector`` is that setting and testing of random bits is
-O(N), and on large ``SparseBitVectors``, this can be slower than ``BitVector``.  In our
+downside to the `SparseBitVector` is that setting and testing of random bits is
+O(N), and on large `SparseBitVectors`, this can be slower than `BitVector`.  In our
 implementation, setting or testing bits in sorted order (either forwards or
 reverse) is O(1) worst case.  Testing and setting bits within 128 bits (depends
 on size) of the current bit is also O(1).  As a general statement,
-testing/setting bits in a ``SparseBitVector`` is O(distance away from last set bit).
+testing/setting bits in a `SparseBitVector` is O(distance away from last set bit).
 
-.. _dss_coalescingbitvector:
+(dss_coalescingbitvector)=
 
-CoalescingBitVector
-^^^^^^^^^^^^^^^^^^^
+#### CoalescingBitVector
 
-The ``CoalescingBitVector`` container is similar in principle to a ``SparseBitVector``,
+The `CoalescingBitVector` container is similar in principle to a `SparseBitVector`,
 but is optimized to represent large contiguous ranges of set bits compactly. It
 does this by coalescing contiguous ranges of set bits into intervals. Searching
-for a bit in a ``CoalescingBitVector`` is O(log(gaps between contiguous ranges)).
+for a bit in a `CoalescingBitVector` is O(log(gaps between contiguous ranges)).
 
-``CoalescingBitVector`` is a better choice than ``BitVector`` when gaps between ranges
-of set bits are large. It's a better choice than ``SparseBitVector`` when find()
+`CoalescingBitVector` is a better choice than `BitVector` when gaps between ranges
+of set bits are large. It's a better choice than `SparseBitVector` when find()
 operations must have fast, predictable performance. However, it's not a good
 choice for representing sets which have lots of very short ranges. E.g. the set
 `{2*x : x \in [0, n)}` would be a pathological input.
 
-.. _utility_functions:
+(utility_functions)=
 
-Useful Utility Functions
-========================
+## Useful Utility Functions
 
 LLVM implements a number of general utility functions used across the
-codebase. You can find the most common ones in ``STLExtras.h``
-(`doxygen <https://llvm.org/doxygen/STLExtras_8h.html>`__). Some of these wrap
+codebase. You can find the most common ones in `STLExtras.h`
+([doxygen](https://llvm.org/doxygen/STLExtras_8h.html)). Some of these wrap
 well-known C++ standard library functions, while others are unique to LLVM.
 
-.. _uf_iteration:
+(uf_iteration)=
 
-Iterating over ranges
----------------------
+### Iterating over ranges
 
 Sometimes you may want to iterate over more than range at a time or know the
 index of the index. LLVM provides custom utility functions to make that easier,
 without having to manually manage all iterators and/or indices:
 
-.. _uf_zip:
+(uf_zip)=
 
-The ``zip``\ * functions
----------------
rnk wrote:

No, it is a regression, that's a good catch. This currently renders as `zip`* publicly, and in reST, the escaped space is necessary to bridge them. I think I should add a check for escape-space to the migration script.

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