4 files changed, 14 insertions, 14 deletions
diff --git a/src/compiler/nir/docs/control_flow.rst b/src/compiler/nir/docs/control_flow.rst
index e10e30bf57..8dff834dd3 100644
--- a/src/compiler/nir/docs/control_flow.rst
+++ b/src/compiler/nir/docs/control_flow.rst
@@ -107,7 +107,7 @@ guarantee. Therefore, optimizations in any intermediate IR must respect this
 invariant, which means that the IR must have a good idea of when control flow
 diverges. For example, in the following snippet:
 
-::
+.. code-block:: c
 
     vec2 color = texture(tex, coordinate * 2.0)
     if (foo) {
@@ -142,7 +142,7 @@ Together, the start block, end block, and graph created by the successors and
 predecessors form the control flow graph that complements the control flow
 tree. For example, this:
 
-::
+.. code-block:: c
 
     void main(void) {
         if (foo)
@@ -273,7 +273,7 @@ be moved. On the basic block level, creating the empty block removes a
 *critical edge*, which is an edge from a block with more than one successor to
 another with more than one predecessor. Consider this if-then statement:
 
-::
+.. code-block:: c
 
     if (foo) {
         bar = 1;
diff --git a/src/compiler/nir/docs/instructions.rst b/src/compiler/nir/docs/instructions.rst
index f016e8d2c3..0fb39a0a9a 100644
--- a/src/compiler/nir/docs/instructions.rst
+++ b/src/compiler/nir/docs/instructions.rst
@@ -65,7 +65,7 @@ opcodes are created using the ``opcode`` function, which constructs the
 object and adds it to the list, as well as various helper functions which call
 ``opcode``. For example, the following line in nir_opcodes.py:
 
-::
+.. code-block:: c
 
     binop("fmul", tfloat, commutative + associative, "src0 * src1")
 
@@ -73,7 +73,7 @@ creates a declaration of a nir_op_fmul member of the ``nir_op`` enum, which is
 defined in the generated file nir_opcodes.h, as well as the following entry in
 the nir_op_infos array (defined in nir_opcodes.c):
 
-::
+.. code-block:: c
     
     {
        .name = "fmul",
@@ -100,7 +100,7 @@ implemented for you, and all you have to do is write the ``some_func``. In
 this case, the definition of ``fmul`` also creates the following code in
 nir_constant_expressions.c:
 
-::
+.. code-block:: c
 
     static nir_const_value
     evaluate_fmul(unsigned num_components, nir_const_value *_src)
@@ -122,7 +122,7 @@ nir_constant_expressions.c:
 
 as well as the following case in ``nir_eval_const_opcode``:
 
-::
+.. code-block:: c
 
    case nir_op_fmul: {
       return evaluate_fmul(num_components, src);
@@ -183,7 +183,7 @@ macros.  nir_intrinsics.h is included twice, once in nir.h to create the
 ``nir_intrinsic_infos`` array. For example, here's the definition of the
 ``store_var`` intrinsic:
 
-::
+.. code-block:: c
 
     INTRINSIC(store_var, 1, ARR(0), false, 0, 1, 0, 0)
 
diff --git a/src/compiler/nir/docs/intro.rst b/src/compiler/nir/docs/intro.rst
index 7e91fa2db3..c7dfdd7d83 100644
--- a/src/compiler/nir/docs/intro.rst
+++ b/src/compiler/nir/docs/intro.rst
@@ -43,7 +43,7 @@ Organization
 NIR is written in C, although in a very object-oriented manner. Structures
 and enums are typedef'ed:
 
-::
+.. code-block:: c
 
     typedef struct nir_foo {
         /* stuff */
@@ -60,7 +60,7 @@ through inline functions defined by the NIR_DEFINE_CAST macro. For example,
 here's how an animal structure inherited by cows, cats, and dogs would be
 defined:
 
-::
+.. code-block:: c
 
     typedef enum {
         nir_animal_type_cow,
diff --git a/src/compiler/nir/docs/variables.rst b/src/compiler/nir/docs/variables.rst
index 12ddd1ed45..5567ebda39 100644
--- a/src/compiler/nir/docs/variables.rst
+++ b/src/compiler/nir/docs/variables.rst
@@ -25,7 +25,7 @@ supports so-called "wildcard" array dereferences, which are used for array
 copies (the ``copy_var`` intrinsic). For example, this allows us to support
 something like:
 
-::
+.. code-block:: c
 
     struct s {
         vec4 a, b;
@@ -33,7 +33,7 @@ something like:
 
     struct s foo[10], bar[10];
     //...
-    foo[*].a = bar[*].a
+    foo[*].a = bar[*].a;
 
 where we can copy part of each element of the array. This is useful because it
 helps make converting part of the variable into SSA easier. For example, if it
@@ -42,13 +42,13 @@ turns out that ``foo[*].a`` (i.e. all the elements ``foo[0].a``, ``foo[1].a``,
 sometimes accessed indirectly, we can convert ``foo[*].a`` to SSA values while
 only keeping around ``foo[*].b``. Therefore, we lower array copies like
 
-::
+.. code-block:: c
 
     foo = bar;
 
 to multiple wildcard copies like
 
-::
+.. code-block:: c
 
     foo[*].a = bar[*].a;
     foo[*].b = bar[*].b;