[docs] Fixing Sphinx warnings to unclog the buildbot

Lots of blocks had "llvm" or "nasm" syntax types but either weren't following the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type doesn't even exist (nasm?). Other documents had :options: what were invalid. I only removed those that had warnings, and left the ones that didn't, in order to follow the principle of least surprise. This is like this for ages, but the buildbot is now failing on errors. It may take a while to upgrade the buildbot's sphinx, if that's even possible, but that shouldn't stop us from getting docs updates (which seem down for quite a while). Also, we're not losing any syntax highlight, since when it doesn't parse, it doesn't colour. Ie. those blocks are not being highlighted anyway. I'm trying to get all docs in one go, so that it's easy to revert later if we do fix, or at least easy to know what's to fix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276109 91177308-0d34-0410-b5e6-96231b3b80d8
ornata · Jul 20, 2016 · 88ea57f · 88ea57f
1 parent 3ac7591
commit 88ea57f
Show file tree

Hide file tree

Showing 22 changed files with 182 additions and 184 deletions.
diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst
@@ -436,7 +436,7 @@ For example, consider this simple LLVM example:
 The X86 instruction selector might produce this machine code for the ``div`` and
 ``ret``:
 
-.. code-block:: llvm
+.. code-block:: text
 
   ;; Start of div
   %EAX = mov %reg1024           ;; Copy X (in reg1024) into EAX
@@ -453,7 +453,7 @@ By the end of code generation, the register allocator would coalesce the
 registers and delete the resultant identity moves producing the following
 code:
 
-.. code-block:: llvm
+.. code-block:: text
 
   ;; X is in EAX, Y is in ECX
   mov %EAX, %EDX
@@ -965,7 +965,7 @@ target code.  For example, consider the following LLVM fragment:
 
 This LLVM code corresponds to a SelectionDAG that looks basically like this:
 
-.. code-block:: llvm
+.. code-block:: text
 
   (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
 

diff --git a/docs/CommandGuide/FileCheck.rst b/docs/CommandGuide/FileCheck.rst
@@ -144,7 +144,7 @@ exists anywhere in the file.
 The FileCheck -check-prefix option
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The FileCheck :option:`-check-prefix` option allows multiple test
+The FileCheck `-check-prefix` option allows multiple test
 configurations to be driven from one `.ll` file.  This is useful in many
 circumstances, for example, testing different architectural variants with
 :program:`llc`.  Here's a simple example:
@@ -303,7 +303,7 @@ be aware that the definition rule can match `after` its use.
 
 So, for instance, the code below will pass:
 
-.. code-block:: llvm
+.. code-block:: text
 
   ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
   ; CHECK-DAG: vmov.32 [[REG2]][1]
@@ -312,7 +312,7 @@ So, for instance, the code below will pass:
 
 While this other code, will not:
 
-.. code-block:: llvm
+.. code-block:: text
 
   ; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
   ; CHECK-DAG: vmov.32 [[REG2]][1]
@@ -473,7 +473,7 @@ To match newline characters in regular expressions the character class
 
 matches output of the form (from llvm-dwarfdump):
 
-.. code-block:: llvm
+.. code-block:: text
 
        DW_AT_location [DW_FORM_sec_offset]   (0x00000233)
        DW_AT_name [DW_FORM_strp]  ( .debug_str[0x000000c9] = "intd")

diff --git a/docs/CommandGuide/llvm-nm.rst b/docs/CommandGuide/llvm-nm.rst
@@ -68,11 +68,11 @@ OPTIONS
 
 .. option:: -B    (default)
 
- Use BSD output format.  Alias for :option:`--format=bsd`.
+ Use BSD output format.  Alias for `--format=bsd`.
 
 .. option:: -P
 
- Use POSIX.2 output format.  Alias for :option:`--format=posix`.
+ Use POSIX.2 output format.  Alias for `--format=posix`.
 
 .. option:: --debug-syms, -a
 

diff --git a/docs/CommandGuide/opt.rst b/docs/CommandGuide/opt.rst
@@ -12,16 +12,16 @@ DESCRIPTION
 The :program:`opt` command is the modular LLVM optimizer and analyzer.  It
 takes LLVM source files as input, runs the specified optimizations or analyses
 on it, and then outputs the optimized file or the analysis results.  The
-function of :program:`opt` depends on whether the :option:`-analyze` option is
+function of :program:`opt` depends on whether the `-analyze` option is
 given.
 
-When :option:`-analyze` is specified, :program:`opt` performs various analyses
+When `-analyze` is specified, :program:`opt` performs various analyses
 of the input source.  It will usually print the results on standard output, but
 in a few cases, it will print output to standard error or generate a file with
 the analysis output, which is usually done when the output is meant for another
 program.
 
-While :option:`-analyze` is *not* given, :program:`opt` attempts to produce an
+While `-analyze` is *not* given, :program:`opt` attempts to produce an
 optimized output file.  The optimizations available via :program:`opt` depend
 upon what libraries were linked into it as well as any additional libraries
 that have been loaded with the :option:`-load` option.  Use the :option:`-help`
@@ -68,19 +68,19 @@ OPTIONS
 
 .. option:: -disable-opt
 
- This option is only meaningful when :option:`-std-link-opts` is given.  It
+ This option is only meaningful when `-std-link-opts` is given.  It
  disables most passes.
 
 .. option:: -strip-debug
 
  This option causes opt to strip debug information from the module before
- applying other optimizations.  It is essentially the same as :option:`-strip`
+ applying other optimizations.  It is essentially the same as `-strip`
  but it ensures that stripping of debug information is done first.
 
 .. option:: -verify-each
 
  This option causes opt to add a verify pass after every pass otherwise
- specified on the command line (including :option:`-verify`).  This is useful
+ specified on the command line (including `-verify`).  This is useful
  for cases where it is suspected that a pass is creating an invalid module but
  it is not clear which pass is doing it.
 

diff --git a/docs/ExceptionHandling.rst b/docs/ExceptionHandling.rst
@@ -406,7 +406,7 @@ outlined.  After the handler is outlined, this intrinsic is simply removed.
 ``llvm.eh.exceptionpointer``
 ----------------------------
 
-.. code-block:: llvm
+.. code-block:: text
 
   i8 addrspace(N)* @llvm.eh.padparam.pNi8(token %catchpad)
 
@@ -427,7 +427,7 @@ backend.  Uses of them are generated by the backend's
 ``llvm.eh.sjlj.setjmp``
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-.. code-block:: llvm
+.. code-block:: text
 
   i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
 
@@ -664,7 +664,7 @@ all of the new IR instructions:
     return 0;
   }
 
-.. code-block:: llvm
+.. code-block:: text
 
   define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 {
   entry:
@@ -741,7 +741,7 @@ C++ code:
     }
   }
 
-.. code-block:: llvm
+.. code-block:: text
 
   define void @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) {
   entry:

diff --git a/docs/Extensions.rst b/docs/Extensions.rst
@@ -43,7 +43,7 @@ The following additional relocation types are supported:
 corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or
 ``IMAGE_REL_AMD64_ADDR32NB`` (64-bit).
 
-.. code-block:: gas
+.. code-block:: text
 
   .text
   fun:

diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst
@@ -204,7 +204,7 @@ IR features is specified by the selected :ref:`GC strategy description
 Specifying GC code generation: ``gc "..."``
 -------------------------------------------
 
-.. code-block:: llvm
+.. code-block:: text
 
   define <returntype> @name(...) gc "name" { ... }
 

diff --git a/docs/GetElementPtr.rst b/docs/GetElementPtr.rst
@@ -105,7 +105,7 @@ memory, or a global variable.
 
 To make this clear, let's consider a more obtuse example:
 
-.. code-block:: llvm
+.. code-block:: text
 
   %MyVar = uninitialized global i32
   ...
@@ -142,7 +142,7 @@ Quick answer: there are no superfluous indices.
 This question arises most often when the GEP instruction is applied to a global
 variable which is always a pointer type. For example, consider this:
 
-.. code-block:: llvm
+.. code-block:: text
 
   %MyStruct = uninitialized global { float*, i32 }
   ...
@@ -178,7 +178,7 @@ The GetElementPtr instruction dereferences nothing. That is, it doesn't access
 memory in any way. That's what the Load and Store instructions are for.  GEP is
 only involved in the computation of addresses. For example, consider this:
 
-.. code-block:: llvm
+.. code-block:: text
 
   %MyVar = uninitialized global { [40 x i32 ]* }
   ...
@@ -195,7 +195,7 @@ illegal.
 In order to access the 18th integer in the array, you would need to do the
 following:
 
-.. code-block:: llvm
+.. code-block:: text
 
   %idx = getelementptr { [40 x i32]* }, { [40 x i32]* }* %, i64 0, i32 0
   %arr = load [40 x i32]** %idx
@@ -204,7 +204,7 @@ following:
 In this case, we have to load the pointer in the structure with a load
 instruction before we can index into the array. If the example was changed to:
 
-.. code-block:: llvm
+.. code-block:: text
 
   %MyVar = uninitialized global { [40 x i32 ] }
   ...

diff --git a/docs/HowToUseInstrMappings.rst b/docs/HowToUseInstrMappings.rst
@@ -30,7 +30,7 @@ instructions with each other. These tables are emitted in the
 ``XXXInstrInfo.inc`` file along with the functions to query them. Following
 is the definition of ``InstrMapping`` class definied in Target.td file:
 
-.. code-block:: llvm
+.. code-block:: text
 
   class InstrMapping {
     // Used to reduce search space only to the instructions using this
@@ -69,7 +69,7 @@ non-predicated form by assigning appropriate values to the ``InstrMapping``
 fields. For this relationship, non-predicated instructions are treated as key
 instruction since they are the one used to query the interface function.
 
-.. code-block:: llvm
+.. code-block:: text
 
   def getPredOpcode : InstrMapping {
     // Choose a FilterClass that is used as a base class for all the
@@ -116,7 +116,7 @@ to include relevant information in its definition. For example, consider
 following to be the current definitions of ADD, ADD_pt (true) and ADD_pf (false)
 instructions:
 
-.. code-block:: llvm
+.. code-block:: text
 
   def ADD : ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
               "$dst = add($a, $b)",
@@ -137,7 +137,7 @@ In this step, we modify these instructions to include the information
 required by the relationship model, <tt>getPredOpcode</tt>, so that they can
 be related.
 
-.. code-block:: llvm
+.. code-block:: text
 
   def ADD : PredRel, ALU32_rr<(outs IntRegs:$dst), (ins IntRegs:$a, IntRegs:$b),
               "$dst = add($a, $b)",

diff --git a/docs/InAlloca.rst b/docs/InAlloca.rst
@@ -41,7 +41,7 @@ that passes two default-constructed ``Foo`` objects to ``g`` in the
       g(Foo(), Foo());
     }
 
-.. code-block:: llvm
+.. code-block:: text
 
     %struct.Foo = type { i32, i32 }
     declare void @Foo_ctor(%struct.Foo* %this)