[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.
llvm-svn: 276109
diff --git a/llvm/docs/TableGen/LangIntro.rst b/llvm/docs/TableGen/LangIntro.rst
index a148634..c1391e7 100644
--- a/llvm/docs/TableGen/LangIntro.rst
+++ b/llvm/docs/TableGen/LangIntro.rst
@@ -232,7 +232,7 @@
Here is a simple TableGen file:
-.. code-block:: llvm
+.. code-block:: text
class C { bit V = 1; }
def X : C;
@@ -276,7 +276,7 @@
value. For example, a new class could be added to the example above, redefining
the ``V`` field for all of its subclasses:
-.. code-block:: llvm
+.. code-block:: text
class D : C { let V = 0; }
def Z : D;
@@ -295,7 +295,7 @@
bindings (which may optionally have defaults) that are bound when used. Here is
a simple example:
-.. code-block:: llvm
+.. code-block:: text
class FPFormat<bits<3> val> {
bits<3> Value = val;
@@ -316,7 +316,7 @@
The more esoteric forms of `TableGen expressions`_ are useful in conjunction
with template arguments. As an example:
-.. code-block:: llvm
+.. code-block:: text
class ModRefVal<bits<2> val> {
bits<2> Value = val;
@@ -346,7 +346,7 @@
actual internal data representation expected by the class. In this case,
running ``llvm-tblgen`` on the example prints the following definitions:
-.. code-block:: llvm
+.. code-block:: text
def bork { // Value
bit isMod = 1;
@@ -379,7 +379,7 @@
Here is an example TableGen fragment that shows this idea:
-.. code-block:: llvm
+.. code-block:: text
def ops;
def GPR;
@@ -405,7 +405,7 @@
multiclass. Using a multiclass this way is exactly equivalent to instantiating
the classes multiple times yourself, e.g. by writing:
-.. code-block:: llvm
+.. code-block:: text
def ops;
def GPR;
@@ -432,7 +432,7 @@
A ``defm`` can also be used inside a multiclass providing several levels of
multiclass instantiations.
-.. code-block:: llvm
+.. code-block:: text
class Instruction<bits<4> opc, string Name> {
bits<4> opcode = opc;
@@ -473,7 +473,7 @@
the class list must start after the last multiclass, and there must be at least
one multiclass before them.
-.. code-block:: llvm
+.. code-block:: text
class XD { bits<4> Prefix = 11; }
class XS { bits<4> Prefix = 12; }
@@ -516,7 +516,7 @@
specified as a double quoted string immediately after the '``include``' keyword.
Example:
-.. code-block:: llvm
+.. code-block:: text
include "foo.td"
@@ -532,7 +532,7 @@
File-scope "let" expressions take a comma-separated list of bindings to apply,
and one or more records to bind the values in. Here are some examples:
-.. code-block:: llvm
+.. code-block:: text
let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
@@ -559,7 +559,7 @@
levels of multiclass instantiations. This also avoids the need of using "let"
expressions within subsequent records inside a multiclass.
-.. code-block:: llvm
+.. code-block:: text
multiclass basic_r<bits<4> opc> {
let Predicates = [HasSSE2] in {
@@ -587,7 +587,7 @@
body, substituting iterator values for iterator references in the body.
Example:
-.. code-block:: llvm
+.. code-block:: text
foreach i = [0, 1, 2, 3] in {
def R#i : Register<...>;
@@ -598,7 +598,7 @@
may be nested. If there is only one item in the body the braces may be
elided:
-.. code-block:: llvm
+.. code-block:: text
foreach i = [0, 1, 2, 3] in
def R#i : Register<...>;
diff --git a/llvm/docs/TableGen/index.rst b/llvm/docs/TableGen/index.rst
index 9526240..5ba555a 100644
--- a/llvm/docs/TableGen/index.rst
+++ b/llvm/docs/TableGen/index.rst
@@ -90,7 +90,7 @@
various definitions expand to fully. Running this on the ``X86.td`` file prints
this (at the time of this writing):
-.. code-block:: llvm
+.. code-block:: text
...
def ADD32rr { // Instruction X86Inst I
@@ -155,7 +155,7 @@
prone to bugs, and tiring to do in the first place. Because we are using
TableGen, all of the information was derived from the following definition:
-.. code-block:: llvm
+.. code-block:: text
let Defs = [EFLAGS],
isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y
@@ -201,7 +201,7 @@
**TableGen definitions** are the concrete form of 'records'. These generally do
not have any undefined values, and are marked with the '``def``' keyword.
-.. code-block:: llvm
+.. code-block:: text
def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
"Enable ARMv8 FP">;
@@ -220,7 +220,7 @@
the classes that are used to build up a definition, so the backend can find all
definitions of a particular class, such as "Instruction".
-.. code-block:: llvm
+.. code-block:: text
class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>;
@@ -235,7 +235,7 @@
sub-multiclass become part of the current multiclass, as if they were declared
in the current multiclass.
-.. code-block:: llvm
+.. code-block:: text
multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
dag address, ValueType sty> {