[Clang-tidy] Fix some checks documentation style

[hokein]

LGTM, thanks!

clang-tools-extra/trunk/docs/clang-tidy/checks/cert-err34-c.rst

 .. title:: clang-tidy - cert-err34-c
 
 cert-err34-c
 ============
 
 This check flags calls to string-to-number conversion functions that do not
 verify the validity of the conversion, such as ``atoi()`` or ``scanf()``. It
 does not flag calls to ``strtol()``, or other, related conversion functions that
 do perform better error checking.
 
-.. code:: c
+.. code-block:: c
 
   #include <stdlib.h>
   
   void func(const char *buff) {
     int si;
     
     if (buff) {
       si = atoi(buff); /* 'atoi' used to convert a string to an integer, but function will

clang-tools-extra/trunk/docs/clang-tidy/checks/cppcoreguidelines-slicing.rst

 .. title:: clang-tidy - cppcoreguidelines-slicing
 
 cppcoreguidelines-slicing
 =========================
 
 Flags slicing of member variables or vtable. Slicing happens when copying a
 derived object into a base object: the members of the derived object (both
-member variables and virtual member functions) will be discarded.
-This can be misleading especially for member function slicing, for example:
+member variables and virtual member functions) will be discarded. This can be
+misleading especially for member function slicing, for example:
 
-.. code:: c++
+.. code-block:: c++
 
-        struct B { int a; virtual int f(); };
-        struct D : B { int b; int f() override; };
-        void use(B b) {  // Missing reference, intended ?
-          b.f();  // Calls B::f.
-        }
-        D d;
-        use(d);  // Slice.
+
+  void use(B b) {  // Missing reference, intended?
+
 
-See the relevant CppCoreGuidelines sections for details:
+See the relevant C++ Core Guidelines sections for details:
 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es63-dont-slice
 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c145-access-polymorphic-objects-through-pointers-and-references

clang-tools-extra/trunk/docs/clang-tidy/checks/google-build-using-namespace.rst

 .. title:: clang-tidy - google-build-using-namespace
 
 google-build-using-namespace
 ============================
 
 Finds ``using namespace`` directives.
 
-https://google.github.io/styleguide/cppguide.html#Namespaces
-
-The check implements the following rule of the Google C++ Style Guide:
+The check implements the following rule of the
+`Google C++ Style Guide <https://google.github.io/styleguide/cppguide.html#Namespaces>`_:
 
   You may not use a using-directive to make all names from a namespace
   available.
 
-  .. code:: c++
+  .. code-block:: c++
 
     // Forbidden -- This pollutes the namespace.
     using namespace foo;
 
 Corresponding cpplint.py check name: `build/namespaces`.

clang-tools-extra/trunk/docs/clang-tidy/checks/google-runtime-member-string-references.rst

 .. title:: clang-tidy - google-runtime-member-string-references
 
 google-runtime-member-string-references
 =======================================
 
 Finds members of type ``const string&``.
 
-const string reference members are generally considered unsafe as they can
-be created from a temporary quite easily.
+const string reference members are generally considered unsafe as they can be
+created from a temporary quite easily.
 
-.. code:: c++
+.. code-block:: c++
 
   struct S {
     S(const string &Str) : Str(Str) {}
     const string &Str;
   };
   S instance("string");
 
-In the constructor call a string temporary is created from ``const char *``
-and destroyed immediately after the call. This leaves around a dangling
-reference.
+In the constructor call a string temporary is created from ``const char *`` and
+destroyed immediately after the call. This leaves around a dangling reference.
 
 This check emit warnings for both ``std::string`` and ``::string`` const
 reference members.
 
 Corresponding cpplint.py check name: `runtime/member_string_reference`.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-bool-pointer-implicit-conversion.rst

 .. title:: clang-tidy - misc-bool-pointer-implicit-conversion
 
 misc-bool-pointer-implicit-conversion
 =====================================
 
 Checks for conditions based on implicit conversion from a ``bool`` pointer to
 ``bool``.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   bool *p;
   if (p) {
     // Never used in a pointer-specific way.
   }
-

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-fold-init-type.rst

 .. title:: clang-tidy - misc-fold-init-type
 
 misc-fold-init-type
 ===================
 
 The check flags type mismatches in
 `folds <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>`_
 like ``std::accumulate`` that might result in loss of precision.
 ``std::accumulate`` folds an input range into an initial value using the type of
 the latter, with ``operator+`` by default. This can cause loss of precision
 through:
 
 - Truncation: The following code uses a floating point range and an int
   initial value, so trucation wil happen at every application of ``operator+``
   and the result will be `0`, which might not be what the user expected.
 
-.. code:: c++
+.. code-block:: c++
 
   auto a = {0.5f, 0.5f, 0.5f, 0.5f};
   return std::accumulate(std::begin(a), std::end(a), 0);
 
 - Overflow: The following code also returns `0`.
 
-.. code:: c++
+.. code-block:: c++
 
   auto a = {65536LL * 65536 * 65536};
   return std::accumulate(std::begin(a), std::end(a), 0);

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-forward-declaration-namespace.rst

 .. title:: clang-tidy - misc-forward-declaration-namespace
 
 misc-forward-declaration-namespace
 ==================================
 
 Checks if an unused forward declaration is in a wrong namespace.
 
 The check inspects all unused forward declarations and checks if there is any
 declaration/definition with the same name existing, which could indicate that
 the forward declaration is in a potentially wrong namespace.
 
-.. code:: c++
+.. code-block:: c++
 
   namespace na { struct A; }
   namespace nb { struct A {}; }
   nb::A a;
   // warning : no definition found for 'A', but a definition with the same name
   // 'A' found in another namespace 'nb::'
 
 This check can only generate warnings, but it can't suggest a fix at this point.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-misplaced-const.rst

 .. title:: clang-tidy - misc-misplaced-const
 
 misc-misplaced-const
 ====================
 
 This check diagnoses when a ``const`` qualifier is applied to a ``typedef`` to a
 pointer type rather than to the pointee, because such constructs are often
 misleading to developers because the ``const`` applies to the pointer rather
 than the pointee.
 
 For instance, in the following code, the resulting type is ``int *`` ``const``
 rather than ``const int *``:
 
-.. code:: c++
+.. code-block:: c++
 
   typedef int *int_ptr;
   void f(const int_ptr ptr);
 
 The check does not diagnose when the underlying ``typedef`` type is a pointer to
 a ``const`` type or a function pointer type. This is because the ``const``
 qualifier is less likely to be mistaken because it would be redundant (or
 disallowed) on the underlying pointee type.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-move-const-arg.rst

 .. title:: clang-tidy - misc-move-const-arg
 
 misc-move-const-arg
 ===================
 
 The check warns
 
-  - if ``std::move()`` is called with a constant argument,
-  - if ``std::move()`` is called with an argument of a trivially-copyable type,
-    or
-  - if the result of ``std::move()`` is passed as a const reference argument.
+
+
 
 In all three cases, the check will suggest a fix that removes the
 ``std::move()``.
 
 Here are examples of each of the three cases:
 
-.. code:: c++
+.. code-block:: c++
 
   const string s;
   return std::move(s);  // Warning: std::move of the const variable has no effect
 
   int x;
   return std::move(x);  // Warning: std::move of the variable of a trivially-copyable type has no effect
 
   void f(const string &s);
   string s;
   f(std::move(s));  // Warning: passing result of std::move as a const reference argument; no move will actually happen

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-multiple-statement-macro.rst

 .. title:: clang-tidy - misc-multiple-statement-macro
 
 misc-multiple-statement-macro
 =============================
 
-Detect multiple statement macros that are used in unbraced conditionals.
-Only the first statement of the macro will be inside the conditional and the other ones will be executed unconditionally.
+Detect multiple statement macros that are used in unbraced conditionals. Only
+the first statement of the macro will be inside the conditional and the other
+ones will be executed unconditionally.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   #define INCREMENT_TWO(x, y) (x)++; (y)++
   if (do_increment)
-    INCREMENT_TWO(a, b);  // `(b)++;` will be executed unconditionally.
-
+    INCREMENT_TWO(a, b);  // (b)++ will be executed unconditionally.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-pointer-and-integral-operation.rst

 .. title:: clang-tidy - misc-pointer-and-integral-operation
 
 misc-pointer-and-integral-operation
 ===================================
 
 Looks for operation involving pointers and integral types. A common mistake is
 to forget to dereference a pointer. These errors may be detected when a pointer
 object is compare to an object with integral type.
 
 Examples:
 
-.. code:: c++
+.. code-block:: c++
 
   char* ptr;
   if ((ptr = malloc(...)) < nullptr)   // Pointer comparison with operator '<'
     ...                                // Should probably be '!='
 
   if (ptr == '\0')   // Should probably be *ptr
     ... 
 
   void Process(std::string path, bool* error) {
     [...]
     if (error != false)  // Should probably be *error
       ...

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-redundant-expression.rst

 .. title:: clang-tidy - misc-redundant-expression
 
 misc-redundant-expression
 =========================
 
 Detect redundant expressions which are typically errors due to copy-paste.
 
 Depending on the operator expressions may be
-  * redundant,
-  * always be `true`,
-  * always be `false`,
-  * always be a constant (zero or one)
+
+- redundant,
+
+- always be ``true``,
+
+- always be ``false``,
+
+- always be a constant (zero or one).
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   ((x+1) | (x+1))             // (x+1) is redundant
   (p->x == p->x)              // always true
   (p->x < p->x)               // always false
   (speed - speed + 1 == 12)   // speed - speed is always zero

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-sizeof-container.rst

 .. title:: clang-tidy - misc-sizeof-container
 
 misc-sizeof-container
 =====================
 
 The check finds usages of ``sizeof`` on expressions of STL container types. Most
 likely the user wanted to use ``.size()`` instead.
 
 All class/struct types declared in namespace ``std::`` having a const ``size()``
 method are considered containers, with the exception of ``std::bitset`` and
 ``std::array``.
 
 Examples:
 
-.. code:: c++
+.. code-block:: c++
 
   std::string s;
   int a = 47 + sizeof(s); // warning: sizeof() doesn't return the size of the container. Did you mean .size()?
 
   int b = sizeof(std::string); // no warning, probably intended.
 
   std::string array_of_strings[10];
   int c = sizeof(array_of_strings) / sizeof(array_of_strings[0]); // no warning, definitely intended.
 
   std::array<int, 3> std_array;
   int d = sizeof(std_array); // no warning, probably intended.
-

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-sizeof-expression.rst

 .. title:: clang-tidy - misc-sizeof-expression
 
 misc-sizeof-expression
 ======================
 
 The check finds usages of ``sizeof`` expressions which are most likely errors.
 
 The ``sizeof`` operator yields the size (in bytes) of its operand, which may be
 an expression or the parenthesized name of a type. Misuse of this operator may
 be leading to errors and possible software vulnerabilities.
 
-
 Suspicious usage of 'sizeof(K)'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------------
+
 A common mistake is to query the ``sizeof`` of an integer literal. This is
 equivalent to query the size of its type (probably ``int``). The intent of the
 programmer was probably to simply get the integer and not its size.
 
-.. code:: c++
+.. code-block:: c++
 
   #define BUFLEN 42
   char buf[BUFLEN];
   memset(buf, 0, sizeof(BUFLEN));  // sizeof(42) ==> sizeof(int)
 
-
 Suspicious usage of 'sizeof(this)'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------------------------------
+
 The ``this`` keyword is evaluated to a pointer to an object of a given type.
 The expression ``sizeof(this)`` is returning the size of a pointer. The
 programmer most likely wanted the size of the object and not the size of the
 pointer.
 
-.. code:: c++
+.. code-block:: c++
 
   class Point {
     [...]
     size_t size() { return sizeof(this); }  // should probably be sizeof(*this)
     [...]  
   };
 
-
 Suspicious usage of 'sizeof(char*)'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------------
+
 There is a subtle difference between declaring a string literal with
 ``char* A = ""`` and ``char A[] = ""``. The first case has the type ``char*``
 instead of the aggregate type ``char[]``. Using ``sizeof`` on an object declared
 with ``char*`` type is returning the size of a pointer instead of the number of
 characters (bytes) in the string literal.
 
-.. code:: c++
+.. code-block:: c++
 
   const char* kMessage = "Hello World!";      // const char kMessage[] = "...";
   void getMessage(char* buf) {
     memcpy(buf, kMessage, sizeof(kMessage));  // sizeof(char*)
   }
 
-
 Suspicious usage of 'sizeof(A*)'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------------------------
+
 A common mistake is to compute the size of a pointer instead of its pointee.
 These cases may occur because of explicit cast or implicit conversion.
 
-.. code:: c++
+.. code-block:: c++
 
   int A[10];
   memset(A, 0, sizeof(A + 0));
 
   struct Point point;
   memset(point, 0, sizeof(&point));
 
-
 Suspicious usage of 'sizeof(...)/sizeof(...)'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------
+
 Dividing ``sizeof`` expressions is typically used to retrieve the number of
 elements of an aggregate. This check warns on incompatible or suspicious cases.
 
 In the following example, the entity has 10-bytes and is incompatible with the
 type ``int`` which has 4 bytes.
 
-.. code:: c++
+.. code-block:: c++
 
   char buf[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };  // sizeof(buf) => 10
   void getMessage(char* dst) {
     memcpy(dst, buf, sizeof(buf) / sizeof(int));  // sizeof(int) => 4  [incompatible sizes]
   }
 
-
 In the following example, the expression ``sizeof(Values)`` is returning the
 size of ``char*``. One can easily be fooled by its declaration, but in parameter
 declaration the size '10' is ignored and the function is receiving a ``char*``.
 
-.. code:: c++
+.. code-block:: c++
 
   char OrderedValues[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
   return CompareArray(char Values[10]) {
     return memcmp(OrderedValues, Values, sizeof(Values)) == 0;  // sizeof(Values) ==> sizeof(char*) [implicit cast to char*]
   }
 
-
 Suspicious 'sizeof' by 'sizeof' expression
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+------------------------------------------
+
 Multiplying ``sizeof`` expressions typically makes no sense and is probably a
 logic error. In the following example, the programmer used ``*`` instead of
 ``/``.
 
-.. code:: c++
+.. code-block:: c++
 
   const char kMessage[] = "Hello World!";
   void getMessage(char* buf) {
     memcpy(buf, kMessage, sizeof(kMessage) * sizeof(char));  //  sizeof(kMessage) / sizeof(char)
   }
 
-
 This check may trigger on code using the arraysize macro. The following code is
 working correctly but should be simplified by using only the ``sizeof``
 operator.
 
-.. code:: c++
+.. code-block:: c++
 
   extern Object objects[100];
   void InitializeObjects() {
     memset(objects, 0, arraysize(objects) * sizeof(Object));  // sizeof(objects)
   }
 
-
 Suspicious usage of 'sizeof(sizeof(...))'
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------------------
+
 Getting the ``sizeof`` of a ``sizeof`` makes no sense and is typically an error
 hidden through macros.
 
-.. code:: c++
+.. code-block:: c++
 
   #define INT_SZ sizeof(int)
   int buf[] = { 42 };
   void getInt(int* dst) {
     memcpy(dst, buf, sizeof(INT_SZ));  // sizeof(sizeof(int)) is suspicious.
   }

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-string-integer-assignment.rst

 .. title:: clang-tidy - misc-string-integer-assignment
 
 misc-string-integer-assignment
 ==============================
 
 The check finds assignments of an integer to ``std::basic_string<CharT>``
 (``std::string``, ``std::wstring``, etc.). The source of the problem is the
 following assignment operator of ``std::basic_string<CharT>``:
 
-.. code:: c++
+.. code-block:: c++
 
   basic_string& operator=( CharT ch );
 
 Numeric types can be implicitly casted to character types.
 
-.. code:: c++
+.. code-block:: c++
 
   std::string s;
   int x = 5965;
   s = 6;
   s = x;
 
 Use the appropriate conversion functions or character literals.
 
-.. code:: c++
+.. code-block:: c++
 
   std::string s;
   int x = 5965;
   s = '6';
   s = std::to_string(x);
 
 In order to suppress false positives, use an explicit cast.
 
-.. code:: c++
+.. code-block:: c++
 
   std::string s;
   s = static_cast<char>(6);

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-string-literal-with-embedded-nul.rst

 .. title:: clang-tidy - misc-string-literal-with-embedded-nul
 
 misc-string-literal-with-embedded-nul
 =====================================
 
 Finds occurences of string literal with embedded NUL character and validates
 their usage.
 
-
 Invalid escaping
-^^^^^^^^^^^^^^^^
+----------------
 
 Special characters can be escaped within a string literal by using their
 hexadecimal encoding like ``\x42``. A common mistake is to escape them
 like this ``\0x42`` where the ``\0`` stands for the NUL character.
 
-.. code:: c++
+.. code-block:: c++
 
   const char* Example[] = "Invalid character: \0x12 should be \x12";
   const char* Bytes[] = "\x03\0x02\0x01\0x00\0xFF\0xFF\0xFF";
 
-
 Truncated literal
-^^^^^^^^^^^^^^^^^
+-----------------
 
-String-like classes can manipulate strings with embedded NUL as they are
-keeping track of the bytes and the length. This is not the case for a
-``char*`` (NUL-terminated) string.
+String-like classes can manipulate strings with embedded NUL as they are keeping
+track of the bytes and the length. This is not the case for a ``char*``
+(NUL-terminated) string.
 
 A common mistake is to pass a string-literal with embedded NUL to a string
 constructor expecting a NUL-terminated string. The bytes after the first NUL
 character are truncated.
 
-.. code:: c++
+.. code-block:: c++
 
   std::string str("abc\0def");  // "def" is truncated
   str += "\0";                  // This statement is doing nothing
   if (str == "\0abc") return;   // This expression is always true

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-suspicious-string-compare.rst

 .. title:: clang-tidy - misc-suspicious-string-compare
 
 misc-suspicious-string-compare
 ==============================
 
 Find suspicious usage of runtime string comparison functions.
 This check is valid in C and C++.
 
 Checks for calls with implicit comparator and proposed to explicitly add it.
 
-.. code:: c++
+.. code-block:: c++
 
     if (strcmp(...))       // Implicitly compare to zero
     if (!strcmp(...))      // Won't warn
     if (strcmp(...) != 0)  // Won't warn
 
-
 Checks that compare function results (i,e, ``strcmp``) are compared to valid
 constant. The resulting value is
 
-.. code::
+.. code-block::
 
     <  0    when lower than,
     >  0    when greater than,
     == 0    when equals.
 
-A common mistake is to compare the result to '1' or '-1'. 
+A common mistake is to compare the result to `1` or `-1`.
 
-.. code:: c++
+.. code-block:: c++
 
     if (strcmp(...) == -1)  // Incorrect usage of the returned value.
 
-
 Additionally, the check warns if the results value is implicitly cast to a
 *suspicious* non-integer type. It's happening when the returned value is used in
 a wrong context.
 
-.. code:: c++
+.. code-block:: c++
 
     if (strcmp(...) < 0.)  // Incorrect usage of the returned value.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-uniqueptr-reset-release.rst

 .. title:: clang-tidy - misc-uniqueptr-reset-release
 
 misc-uniqueptr-reset-release
 ============================
 
-
 Find and replace ``unique_ptr::reset(release())`` with ``std::move()``.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   std::unique_ptr<Foo> x, y;
   x.reset(y.release()); -> x = std::move(y);
 
-If ``y`` is already rvalue, ``std::move()`` is not added.  ``x`` and ``y`` can also
-be ``std::unique_ptr<Foo>*``.
+If ``y`` is already rvalue, ``std::move()`` is not added. ``x`` and ``y`` can
+also be ``std::unique_ptr<Foo>*``.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-unused-raii.rst

 .. title:: clang-tidy - misc-unused-raii
 
 misc-unused-raii
 ================
 
-
 Finds temporaries that look like RAII objects.
 
 The canonical example for this is a scoped lock.
 
-.. code:: c++
+.. code-block:: c++
 
   {
     scoped_lock(&global_mutex);
     critical_section();
   }
 
 The destructor of the scoped_lock is called before the ``critical_section`` is
 entered, leaving it unprotected.
 
 We apply a number of heuristics to reduce the false positive count of this
 check:
 
-  * Ignore code expanded from macros. Testing frameworks make heavy use of this.
-  * Ignore types with trivial destructors. They are very unlikely to be RAII
-    objects and there's no difference when they are deleted.
-  * Ignore objects at the end of a compound statement (doesn't change behavior).
-  * Ignore objects returned from a call.
+- Ignore code expanded from macros. Testing frameworks make heavy use of this.
+
+- Ignore types with trivial destructors. They are very unlikely to be RAII
+
+- Ignore objects at the end of a compound statement (doesn't change behavior).
+
+- Ignore objects returned from a call.

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-unused-using-decls.rst

 .. title:: clang-tidy - misc-unused-using-decls
 
 misc-unused-using-decls
 =======================
 
 Finds unused ``using`` declarations.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   namespace n { class C; }
   using n::C;  // Never actually used.
-

clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-avoid-bind.rst

 .. title:: clang-tidy - modernize-avoid-bind
 
 modernize-avoid-bind
 ====================
 
 The check finds uses of ``std::bind`` and replaces simple uses with lambdas.
 Lambdas will use value-capture where required.
 
 Right now it only handles free functions, not member functions.
 
 Given:
 
-.. code:: c++
+.. code-block:: c++
 
   int add(int x, int y) { return x + y; }
 
 Then:
 
-.. code:: c++
+.. code-block:: c++
 
   void f() {
     int x = 2;
     auto clj = std::bind(add, x, _1);
   }
 
 is replaced by:
 
-.. code:: c++
+.. code-block:: c++
 
   void f() {
     int x = 2;
     auto clj = [=](auto && arg1) { return add(x, arg1); };
   }
 
 ``std::bind`` can be hard to read and can result in larger object files and
 binaries due to type information that will not be produced by equivalent
 lambdas.
-

clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-using.rst

 .. title:: clang-tidy - modernize-use-using
 
 modernize-use-using
 ===================
 
-Use C++11's ``using`` instead of ``typedef``.
+The check converts the usage of ``typedef`` with ``using`` keyword.
 
 Before:
 
-.. code:: c++
+.. code-block:: c++
 
   typedef int variable;
 
   class Class{};
   typedef void (Class::* MyPtrType)() const;
 
 After:
 
-.. code:: c++
+.. code-block:: c++
 
   using variable = int;
 
   class Class{};
   using MyPtrType = void (Class::*)() const;
 
 This check requires using C++11 or higher to run.

clang-tools-extra/trunk/docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst

 .. title:: clang-tidy - performance-implicit-cast-in-loop
 
 performance-implicit-cast-in-loop
 =================================
 
 This warning appears in a range-based loop with a loop variable of const ref
 type where the type of the variable does not match the one returned by the
-iterator.
-This means that an implicit cast has been added, which can for example result in
-expensive deep copies.
+iterator. This means that an implicit cast has been added, which can for example
+result in expensive deep copies.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
-   map<int, vector<string>> my_map;
-   for (const pair<int, vector<string>>& p : my_map) {}
-   // The iterator type is in fact pair<const int, vector<string>>, which means
-   // that the compiler added a cast, resulting in a copy of the vectors.
 
 The easiest solution is usually to use ``const auto&`` instead of writing the type
 manually.

clang-tools-extra/trunk/docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst

 .. title:: clang-tidy - performance-inefficient-string-concatenation
 
 performance-inefficient-string-concatenation
 ============================================
 
-This check warns about the performance overhead arising from concatenating strings using the ``operator+``, for instance:
+This check warns about the performance overhead arising from concatenating
+strings using the ``operator+``, for instance:
     
-.. code:: c++
+.. code-block:: c++
 
     std::string a("Foo"), b("Bar");
     a = a + b;
 
-Instead of this structure you should use ``operator+=`` or ``std::string``'s (``std::basic_string``) class member function ``append()``. For instance:
+Instead of this structure you should use ``operator+=`` or ``std::string``'s
+(``std::basic_string``) class member function ``append()``. For instance:
    
-.. code:: c++
+.. code-block:: c++
 
    std::string a("Foo"), b("Baz");
    for (int i = 0; i < 20000; ++i) {
        a = a + "Bar" + b;
    }
 
 Could be rewritten in a greatly more efficient way like:
 
-.. code:: c++
+.. code-block:: c++
 
    std::string a("Foo"), b("Baz");
    for (int i = 0; i < 20000; ++i) {
        a.append("Bar").append(b);
    } 
 
 And this can be rewritten too:
 
-.. code:: c++
+.. code-block:: c++
 
    void f(const std::string&) {}
    std::string a("Foo"), b("Baz");
    void g() {
        f(a + "Bar" + b);
    }
 
 In a slightly more efficient way like:
 
-.. code:: c++
+.. code-block:: c++
 
    void f(const std::string&) {}
    std::string a("Foo"), b("Baz");
    void g() {
        f(std::string(a).append("Bar").append(b));
    }

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-avoid-const-params-in-decls.rst

 .. title:: clang-tidy - readability-avoid-const-params-in-decls
 
 readability-avoid-const-params-in-decls
 =======================================
 
-Checks whether a function declaration has parameters that are top level const.
+Checks whether a function declaration has parameters that are top level
+``const``.
 
-`const` values in declarations do not affect the signature of a function, so
-they should not be put there.  For example:
+``const`` values in declarations do not affect the signature of a function, so
+they should not be put there.
 
 Examples:
 
-.. code:: c++
+.. code-block:: c++
 
   void f(const string);   // Bad: const is top level.
   void f(const string&);  // Good: const is not top level.
-

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-deleted-default.rst

 .. title:: clang-tidy - readability-deleted-default
 
 readability-deleted-default
 ===========================
 
 Checks that constructors and assignment operators marked as ``= default`` are
 not actually deleted by the compiler.
 
-.. code:: c++
+.. code-block:: c++
 
   class Example {
   public:
     // This constructor is deleted because I is missing a default value.
     Example() = default;
     // This is fine.
     Example(const Example& Other) = default;
     // This operator is deleted because I cannot be assigned (it is const).
     Example& operator=(const Example& Other) = default;
+
   private:
     const int I;
   };
-

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-implicit-bool-cast.rst

 .. title:: clang-tidy - readability-implicit-bool-cast
 
 readability-implicit-bool-cast
 ==============================
 
 This check can be used to find implicit conversions between built-in types and
 booleans. Depending on use case, it may simply help with readability of the code,
 or in some cases, point to potential bugs which remain unnoticed due to implicit
 conversions.
 
 The following is a real-world example of bug which was hiding behind implicit
-bool cast:
+``bool`` cast:
 
-.. code:: c++
+.. code-block:: c++
 
   class Foo {
     int m_foo;
+
   public:
     void setFoo(bool foo) { m_foo = foo; } // warning: implicit cast bool -> int
     int getFoo() { return m_foo; }
   };
 
   void use(Foo& foo) {
     bool value = foo.getFoo(); // warning: implicit cast int -> bool
   }
 
 This code is the result of unsuccessful refactoring, where type of ``m_foo``
 changed from ``bool`` to ``int``. The programmer forgot to change all
 occurrences of ``bool``, and the remaining code is no longer correct, yet it
 still compiles without any visible warnings.
 
-In addition to issuing warnings, FixIt hints are provided to help solve
-the reported issues. This can be used for improving readability of code, for example:
+In addition to issuing warnings, fix-it hints are provided to help solve the
+reported issues. This can be used for improving readability of code, for
+example:
 
-.. code:: c++
+.. code-block:: c++
 
   void conversionsToBool() {
     float floating;
     bool boolean = floating;
     // ^ propose replacement: bool boolean = floating != 0.0f;
 
     int integer;
     if (integer) {}
void conversionsFromBool() {
     functionTakingInt(boolean);
     // ^ propose replacement: functionTakingInt(static_cast<int>(boolean));
 
     functionTakingInt(true);
     // ^ propose replacement: functionTakingInt(1);
   }
 
 In general, the following cast types are checked:
- - integer expression/literal to boolean,
- - floating expression/literal to boolean,
- - pointer/pointer to member/``nullptr``/``NULL`` to boolean,
- - boolean expression/literal to integer,
- - boolean expression/literal to floating.
+
+
+
+
+
 
-The rules for generating FixIt hints are:
- - in case of casts from other built-in type to bool, an explicit comparison
-   is proposed to make it clear what exaclty is being compared:
+The rules for generating fix-it hints are:
+
 
-   - ``bool boolean = floating;`` is changed to ``bool boolean = floating == 0.0f;``,
-   - for other types, appropriate literals are used (``0``, ``0u``, ``0.0f``, ``0.0``, ``nullptr``),
- - in case of negated expressions cast to bool, the proposed replacement with
-   comparison is simplified:
+  - ``bool boolean = floating;`` is changed to
+  ``bool boolean = floating == 0.0f;``,
+
+  - for other types, appropriate literals are used (``0``, ``0u``, ``0.0f``,
+  ``0.0``, ``nullptr``),
+
 
-   - ``if (!pointer)`` is changed to ``if (pointer == nullptr)``,
- - in case of casts from bool to other built-in types, an explicit ``static_cast``
-   is proposed to make it clear that a cast is taking place:
+
 
-   - ``int integer = boolean;`` is changed to ``int integer = static_cast<int>(boolean);``,
- - if the cast is performed on type literals, an equivalent literal is proposed,
-   according to what type is actually expected, for example:
+  - ``int integer = boolean;`` is changed to
+  ``int integer = static_cast<int>(boolean);``,
+
 
-   - ``functionTakingBool(0);`` is changed to ``functionTakingBool(false);``,
-   - ``functionTakingInt(true);`` is changed to ``functionTakingInt(1);``,
-   - for other types, appropriate literals are used (``false``, ``true``, ``0``, ``1``, ``0u``, ``1u``,
-     ``0.0f``, ``1.0f``, ``0.0``, ``1.0f``).
+
+
+  - for other types, appropriate literals are used (``false``, ``true``, ``0``,
+    ``1``, ``0u``, ``1u``, ``0.0f``, ``1.0f``, ``0.0``, ``1.0f``).
 
 Some additional accommodations are made for pre-C++11 dialects:
- - ``false`` literal cast to pointer is detected,
- - instead of ``nullptr`` literal, ``0`` is proposed as replacement.
+
+
 
 Occurrences of implicit casts inside macros and template instantiations are
 deliberately ignored, as it is not clear how to deal with such cases.

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst

 .. title:: clang-tidy - readability-inconsistent-declaration-parameter-name
 
 readability-inconsistent-declaration-parameter-name
 ===================================================
 
-
 Find function declarations which differ in parameter names.
 
 Example:
 
-.. code:: c++
+.. code-block:: c++
 
   // in foo.hpp:
   void foo(int a, int b, int c);
 
   // in foo.cpp:
   void foo(int d, int e, int f); // warning
 
 This check should help to enforce consistency in large projects, where it often
 happens that a definition of function is refactored, changing the parameter
 names, but its declaration in header file is not updated. With this check, we
 can easily find and correct such inconsistencies, keeping declaration and
 definition always in sync.
 
 Unnamed parameters are allowed and are not taken into account when comparing
 function declarations, for example:
 
-.. code:: c++
+.. code-block:: c++
 
-   void foo(int a);
-   void foo(int); // no warning
 
-To help with refactoring, in some cases FixIt hints are generated to align
+To help with refactoring, in some cases fix-it hints are generated to align
 parameter names to a single naming convention. This works with the assumption
 that the function definition is the most up-to-date version, as it directly
 references parameter names in its body. Example:
 
-.. code:: c++
+.. code-block:: c++
 
-   void foo(int a); // warning and FixIt hint (replace "a" to "b")
-   int foo(int b) { return b + 2; } // definition with use of "b"
+  void foo(int a); // warning and fix-it hint (replace "a" to "b")
 
 In the case of multiple redeclarations or function template specializations,
 a warning is issued for every redeclaration or specialization inconsistent with
 the definition or the first declaration seen in a translation unit.

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-redundant-string-init.rst

 .. title:: clang-tidy - readability-redundant-string-init
 
 readability-redundant-string-init
 =================================
 
-
 Finds unnecessary string initializations.
 
 Examples:
 
-.. code:: c++
+.. code-block:: c++
 
   // Initializing string with empty string literal is unnecessary.
   std::string a = "";
   std::string b("");

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-static-definition-in-anonymous-namespace.rst

 .. title:: clang-tidy - readability-static-definition-in-anonymous-namespace
 
 readability-static-definition-in-anonymous-namespace
 ====================================================
 
 Finds static function and variable definitions in anonymous namespace.
 
 In this case, ``static`` is redundant, because anonymous namespace limits the
 visibility of definitions to a single translation unit.
 
-.. code:: c++
+.. code-block:: c++
 
   namespace {
     static int a = 1; // Warning.
     static const b = 1; // Warning.
   }
 
 The check will apply a fix by removing the redundant ``static`` qualifier.