[Docs] Fix code-blocks missing colon

[rogfer01]

Summary

I was reading ORCv2 HTML documentation and I found the text mentioned examples that were not present. Turns out there were some syntax issues in the reStructuedText file that prevented rendering them.

I did a grep through the rest of the docs and I found a few other instances of the problem, including missing newlines.

I was pleased to discover that clang attributes nodiscard / warn_unused_result had a couple useful example that had never been rendered!

[PiotrZSL]

Thank you.
LGTM

[aaron.ballman]

LGTM, good catch! It'd be nice if we could somehow configure Sphinx to complain about this issue so we'd catch it proactively with the sphinx build bots.

clang-tools-extra/docs/clang-tidy/checks/bugprone/bad-signal-to-kill-thread.rst

 .. title:: clang-tidy - bugprone-bad-signal-to-kill-thread
 
 bugprone-bad-signal-to-kill-thread
 ==================================
 
 Finds ``pthread_kill`` function calls when a thread is terminated by
 raising ``SIGTERM`` signal and the signal kills the entire process, not
 just the individual thread. Use any signal except ``SIGTERM``.
 
-.. code-block: c++
+.. code-block:: c++
 
     pthread_kill(thread, SIGTERM);
 
 This check corresponds to the CERT C Coding Standard rule
 `POS44-C. Do not use signals to terminate threads
 <https://wiki.sei.cmu.edu/confluence/display/c/POS44-C.+Do+not+use+signals+to+terminate+threads>`_.

clang-tools-extra/docs/clang-tidy/checks/bugprone/spuriously-wake-up-functions.rst

 .. title:: clang-tidy - bugprone-spuriously-wake-up-functions
 
 bugprone-spuriously-wake-up-functions
 =====================================
 
 Finds ``cnd_wait``, ``cnd_timedwait``, ``wait``, ``wait_for``, or
 ``wait_until`` function calls when the function is not invoked from a loop
 that checks whether a condition predicate holds or the function has a
 condition parameter.
 
-.. code-block: c++
+.. code-block:: c++
 
     if (condition_predicate) {
         condition.wait(lk);
     }
 
-.. code-block: c
+.. code-block:: c
 
     if (condition_predicate) {
         if (thrd_success != cnd_wait(&condition, &lock)) {
         }
     }
 
 This check corresponds to the CERT C++ Coding Standard rule
 `CON54-CPP. Wrap functions that can spuriously wake up in a loop
 <https://wiki.sei.cmu.edu/confluence/display/cplusplus/CON54-CPP.+Wrap+functions+that+can+spuriously+wake+up+in+a+loop>`_.
 and CERT C Coding Standard rule
 `CON36-C. Wrap functions that can spuriously wake up in a loop
 <https://wiki.sei.cmu.edu/confluence/display/c/CON36-C.+Wrap+functions+that+can+spuriously+wake+up+in+a+loop>`_.

clang-tools-extra/docs/clang-tidy/checks/concurrency/thread-canceltype-asynchronous.rst

 .. title:: clang-tidy - concurrency-thread-canceltype-asynchronous
 
 concurrency-thread-canceltype-asynchronous
 ==========================================
 
 Finds ``pthread_setcanceltype`` function calls where a thread's cancellation
 type is set to asynchronous. Asynchronous cancellation type
 (``PTHREAD_CANCEL_ASYNCHRONOUS``) is generally unsafe, use type
 ``PTHREAD_CANCEL_DEFERRED`` instead which is the default. Even with deferred
 cancellation, a cancellation point in an asynchronous signal handler may still
 be acted upon and the effect is as if it was an asynchronous cancellation.
 
-.. code-block: c++
+.. code-block:: c++
 
   pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
 
 This check corresponds to the CERT C Coding Standard rule
 `POS47-C. Do not use threads that can be canceled asynchronously
 <https://wiki.sei.cmu.edu/confluence/display/c/POS47-C.+Do+not+use+threads+that+can+be+canceled+asynchronously>`_.

clang/include/clang/Basic/AttrDocs.td

 when the entity cannot be removed. For instance, a local variable may exist
 solely for use in an ``assert()`` statement, which makes the local variable
 unused when ``NDEBUG`` is defined.
 
 The attribute may be applied to the declaration of a class, a typedef, a
 variable, a function or method, a function parameter, an enumeration, an
 enumerator, a non-static data member, or a label.
 
-.. code-block: c++
+.. code-block:: c++
+
   #include <cassert>
 
   [[maybe_unused]] void f([[maybe_unused]] bool thing1,
                           [[maybe_unused]] bool thing2) {
     [[maybe_unused]] bool b = thing1 && thing2;
     assert(b);
   }
   }];

 
 A string literal may optionally be provided to the attribute, which will be
 reproduced in any resulting diagnostics. Redeclarations using different forms
 of the attribute (with or without the string literal or with different string
 literal contents) are allowed. If there are redeclarations of the entity with
 differing string literals, it is unspecified which one will be used by Clang
 in any resulting diagnostics.
 
-.. code-block: c++
+.. code-block:: c++
+
   struct [[nodiscard]] error_info { /*...*/ };
   error_info enable_missile_safety_mode();
 
   void launch_missiles();
   void test_missiles() {
     enable_missile_safety_mode(); // diagnoses
     launch_missiles();
   }
   error_info &foo();
   void f() { foo(); } // Does not diagnose, error_info is a reference.
 
 Additionally, discarded temporaries resulting from a call to a constructor
 marked with ``[[nodiscard]]`` or a constructor of a type marked
 ``[[nodiscard]]`` will also diagnose. This also applies to type conversions that
 use the annotated ``[[nodiscard]]`` constructor or result in an annotated type.
 
-.. code-block: c++
+.. code-block:: c++
+
   struct [[nodiscard]] marked_type {/*..*/ };
   struct marked_ctor {
     [[nodiscard]] marked_ctor();
     marked_ctor(int);
   };
 
   struct S {
     operator marked_type() const;
.. code-block:: c
   };
   struct S __attribute__((noderef)) *s;
   p = &s->a;
   p = &(*s).a;
 
 ``noderef`` is currently only supported for pointers and arrays and not usable
 for references or Objective-C object pointers.
 
-.. code-block: c++
+.. code-block:: c++
 
   int x = 2;
   int __attribute__((noderef)) &y = x;  // warning: 'noderef' can only be used on an array or pointer type
 
-.. code-block: objc
+.. code-block:: objc
 
   id __attribute__((noderef)) obj = [NSObject new]; // warning: 'noderef' can only be used on an array or pointer type
 }];
 }
 
 def ReinitializesDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

clang/include/clang/Basic/DiagnosticGroups.td

 invocation.
 
 The diagnostic information can be saved to a file in a machine readable format,
 like YAML by adding the `-foptimization-record-file=<file>` command-line flag.
 
 Results can be filtered by function name by passing
 `-mllvm -filter-print-funcs=foo`, where `foo` is the target function's name.
 
-   .. code-block: console
+   .. code-block:: console
+
       clang -c a.cpp -Rpass-analysis=stack-frame-layout -mllvm -filter-print-funcs=foo
 
-   .. code-block: console
+   .. code-block:: console
+
       clang -c a.cpp -Rpass-analysis=stack-frame-layout -foptimization-record-file=<file>
 }];
 }
 // Compatibility flag name from old versions of Clang.
 def : DiagGroup<"frame-larger-than=", [BackendFrameLargerThan]>;
 def BackendPlugin : DiagGroup<"backend-plugin">;
 def RemarkBackendPlugin : DiagGroup<"remark-backend-plugin">;
 def BackendOptimizationRemark : DiagGroup<"pass">;

 def MaxTokens : DiagGroup<"max-tokens"> {
   code Documentation = [{
 The warning is issued if the number of pre-processor tokens exceeds
 the token limit, which can be set in three ways:
 
 1. As a limit at a specific point in a file, using the ``clang max_tokens_here``
    pragma:
 
-   .. code-block: c++
+   .. code-block:: c++
+
       #pragma clang max_tokens_here 1234
 
 2. As a per-translation unit limit, using the ``-fmax-tokens=`` command-line
    flag:
 
-   .. code-block: console
+   .. code-block:: console
+
       clang -c a.cpp -fmax-tokens=1234
 
 3. As a per-translation unit limit using the ``clang max_tokens_total`` pragma,
    which works like and overrides the ``-fmax-tokens=`` flag:
 
-   .. code-block: c++
+   .. code-block:: c++
+
       #pragma clang max_tokens_total 1234
 
 These limits can be helpful in limiting code growth through included files.
 
 Setting a token limit of zero means no limit.
 
 Note that the warning is disabled by default, so -Wmax-tokens must be used
 in addition with the pragmas or -fmax-tokens flag to get any warnings.

llvm/docs/ORCv2.rst

 
 Absolute Symbols
 ----------------
 
 Absolute symbols are symbols that map directly to addresses without requiring
 further materialization, for example: "foo" = 0x1234. One use case for
 absolute symbols is allowing resolution of process symbols. E.g.
 
-.. code-block: c++
+.. code-block:: c++
 
   JD.define(absoluteSymbols(SymbolMap({
       { Mangle("printf"),
         { ExecutorAddr::fromPtr(&printf),
           JITSymbolFlags::Callable } }
     });
 
 With this mapping established code added to the JIT can refer to printf
 symbolically rather than requiring the address of printf to be "baked in".
 This in turn allows cached versions of the JIT'd code (e.g. compiled objects)
 to be re-used across JIT sessions as the JIT'd code no longer changes, only the
 absolute symbol definition does.
 
 For process and library symbols the DynamicLibrarySearchGenerator utility (See
 :ref:`How to Add Process and Library Symbols to JITDylibs
 <ProcessAndLibrarySymbols>`) can be used to automatically build absolute
 symbol mappings for you. However the absoluteSymbols function is still useful
 for making non-global objects in your JIT visible to JIT'd code. For example,
 imagine that your JIT standard library needs access to your JIT object to make
 some calls. We could bake the address of your object into the library, but then
 it would need to be recompiled for each session:
 
-.. code-block: c++
+.. code-block:: c++
 
   // From standard library for JIT'd code:
 
   class MyJIT {
   public:
     void log(const char *Msg);
   };
 
   void log(const char *Msg) { ((MyJIT*)0x1234)->log(Msg); }
 
 We can turn this into a symbolic reference in the JIT standard library:
 
-.. code-block: c++
+.. code-block:: c++
 
   extern MyJIT *__MyJITInstance;
 
   void log(const char *Msg) { __MyJITInstance->log(Msg); }
 
 And then make our JIT object visible to the JIT standard library with an
 absolute symbol definition when the JIT is started:
 
-.. code-block: c++
+.. code-block:: c++
 
   MyJIT J = ...;
 
   auto &JITStdLibJD = ... ;
 
   JITStdLibJD.define(absoluteSymbols(SymbolMap({
       { Mangle("__MyJITInstance"),
         { ExecutorAddr::fromPtr(&J), JITSymbolFlags() } }
     });
 
 Aliases and Reexports
 ---------------------
 
 Aliases and reexports allow you to define new symbols that map to existing
 symbols. This can be useful for changing linkage relationships between symbols
 across sessions without having to recompile code. For example, imagine that
 JIT'd code has access to a log function, ``void log(const char*)`` for which
 there are two implementations in the JIT standard library: ``log_fast`` and
 ``log_detailed``. Your JIT can choose which one of these definitions will be
 used when the ``log`` symbol is referenced by setting up an alias at JIT startup
 time:
 
-.. code-block: c++
+.. code-block:: c++
 
   auto &JITStdLibJD = ... ;
 
   auto LogImplementationSymbol =
    Verbose ? Mangle("log_detailed") : Mangle("log_fast");
 
   JITStdLibJD.define(
     symbolAliases(SymbolAliasMap({
         { Mangle("log"),
           { LogImplementationSymbol
             JITSymbolFlags::Exported | JITSymbolFlags::Callable } }
       });
 
 The ``symbolAliases`` function allows you to define aliases within a single
 JITDylib. The ``reexports`` function provides the same functionality, but
 operates across JITDylib boundaries. E.g.
 
-.. code-block: c++
+.. code-block:: c++
 
   auto &JD1 = ... ;
   auto &JD2 = ... ;
 
   // Make 'bar' in JD2 an alias for 'foo' from JD1.
   JD2.define(
     reexports(JD1, SymbolAliasMap({
         { Mangle("bar"), { Mangle("foo"), JITSymbolFlags::Exported } }