Merge pull request #3093 from nschonni/fix--MD030/list-marker-space

fix: MD030/list-marker-space

Author: gewarren

.markdownlint.json

@@ -19,7 +19,6 @@
     "MD027": false,
     "MD028": false,
     "MD029": false,
-    "MD030": false,
     "MD031": false,
     "MD032": false,
     "MD033": {

docs/azure/vs-azure-tools-configure-roles-for-cloud-service.md

@@ -250,7 +250,7 @@ The following code shows an example of how to write a text file to local storage
 
 To view the file created by the code in the previous section, follow these steps:
 
-1.  In the Windows notification area, right-click the Azure icon, and, from the context menu, select **Show Compute Emulator UI**.
+1. In the Windows notification area, right-click the Azure icon, and, from the context menu, select **Show Compute Emulator UI**.
 
     ![Show Azure compute emulator](./media/vs-azure-tools-configure-roles-for-cloud-service/show-compute-emulator.png)
 

docs/code-quality/C26416.md

@@ -22,10 +22,10 @@ R.34: Take a shared_ptr\<widget> parameter to express that a function is part ow
 Passing a shared pointer by rvalue reference is usually unnecessary. Unless it is an implementation of move semantics for a shared pointer type itself, shared pointer objects can be safely passed by value. Using rvalue reference may be also an indication that unique pointer is more appropriate since it clearly transfers unique ownership from caller to callee.
 
 ## Remarks
--  This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
--  overloaded dereference or member access operators (public and non-deleted);
--  copy constructor or copy assignment operator (public and non-deleted);
--  public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
+- This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
+- overloaded dereference or member access operators (public and non-deleted);
+- copy constructor or copy assignment operator (public and non-deleted);
+- public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
 
 ## Example
 questionable constructor optimization

docs/code-quality/C26417.md

@@ -22,13 +22,13 @@ R.35: Take a shared_ptr\<widget>& parameter to express that a function might res
 Passing shared pointers by reference may be useful in scenarios where callee code updates target of the smart pointer object and its caller expects to see such update. Using a reference solely to reduce costs of passing a shared pointer is questionable. If callee code only accesses target object and never manages its lifetime, it is safer to pass raw pointer or reference, rather than to expose resource management details.
 
 ## Remarks
--  This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
--  overloaded dereference or member access operators (public and non-deleted);
--  copy constructor or copy assignment operator (public and non-deleted);
--  public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
--  The action of resetting or reassigning is interpreted in a more generic way:
--  any call to a non-constant function on a shared pointer can potentially reset the pointer;
--  any call to a function which accepts a reference to a non-constant shared pointer can potentially reset or reassign that pointer.
+- This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
+- overloaded dereference or member access operators (public and non-deleted);
+- copy constructor or copy assignment operator (public and non-deleted);
+- public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
+- The action of resetting or reassigning is interpreted in a more generic way:
+- any call to a non-constant function on a shared pointer can potentially reset the pointer;
+- any call to a function which accepts a reference to a non-constant shared pointer can potentially reset or reassign that pointer.
 
 ## Example
 unnecessary interface complication

docs/code-quality/C26418.md

@@ -22,10 +22,10 @@ R.36: Take a const shared_ptr\<widget>& parameter to express that it might retai
 If shared pointer parameter is passed by value or reference to a constant object it is expected that function will take control of its target object’s lifetime without affecting of the caller. The code should either copy or move the shared pointer parameter to another shared pointer object or pass it further to other code by invoking functions which accept shared pointers. If this is not the case, then plain pointer or reference may be feasible.
 
 ## Remarks
--  This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
--  overloaded dereference or member access operators (public and non-deleted);
--  copy constructor or copy assignment operator (public and non-deleted);
--  public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
+- This check recognizes std::shared_pointer and user-defined types which are likely to behave like shared pointers. The following traits are expected for user-defined shared pointers:
+- overloaded dereference or member access operators (public and non-deleted);
+- copy constructor or copy assignment operator (public and non-deleted);
+- public destructor which is neither deleted nor defaulted. Empty destructors are still counted as user-defined.
 
 ## Example
 unnecessary interface complication

docs/code-quality/C26432.md

@@ -23,11 +23,11 @@ Special operations like constructors are assumed to alter behavior of types so t
 
 ## Remarks
 - This check implements "the rule of five" which treats the following operations as special:
-  -  copy constructors;
-  -  move constructors;
-  -  copy assignment operators;
-  -  move assignment operators;
-  -  destructors;
-  -  The rule doesn’t check if operations are defined in the same way, i.e. it is okay to mix deleted and defaulted operations with explicitly defined, but they all must be specified somehow if any of them appears.
-  -  Access levels are not important and can also be mixed.
-  -  The warning flags the first non-static function definition of a type, once per type.
+  - copy constructors;
+  - move constructors;
+  - copy assignment operators;
+  - move assignment operators;
+  - destructors;
+  - The rule doesn’t check if operations are defined in the same way, i.e. it is okay to mix deleted and defaulted operations with explicitly defined, but they all must be specified somehow if any of them appears.
+  - Access levels are not important and can also be mixed.
+  - The warning flags the first non-static function definition of a type, once per type.

docs/code-quality/C26436.md

@@ -23,4 +23,4 @@ If a class defines a virtual function it becomes polymorphic, which implies that
 
 ## Remarks
 - The warning shows up on the first virtual function definition of a type (it can be a virtual destructor if it is not public), once per type.
-  -  Since definition can be placed separately from declaration, it may not always have any of the virtual specifiers. But the warning is still valid – it checks the actual ‘virtuality’ of a function.
+  - Since definition can be placed separately from declaration, it may not always have any of the virtual specifiers. But the warning is still valid – it checks the actual ‘virtuality’ of a function.

docs/code-quality/C26439.md

@@ -23,10 +23,10 @@ Some kinds of operations should never cause exceptions. Their implementations sh
 
 ## Remarks
 - Special kinds of operations are the following:
-  -  destructors;
-  -  default constructors;
-  -  move constructors and move assignment operators;
-  -  standard functions with move semantics: std::move and std::swap.
-  -  Non-standard and outdated specifiers like throw() or declspec(nothrow) are not equivalent to ‘noexcept’.
-  -  Explicit specifiers noexcept(false) and noexcept(true) are respected appropriately.
-  -  The warning may still appear for operations that are marked as constexpr. This may change in future releases.
+  - destructors;
+  - default constructors;
+  - move constructors and move assignment operators;
+  - standard functions with move semantics: std::move and std::swap.
+  - Non-standard and outdated specifiers like throw() or declspec(nothrow) are not equivalent to ‘noexcept’.
+  - Explicit specifiers noexcept(false) and noexcept(true) are respected appropriately.
+  - The warning may still appear for operations that are marked as constexpr. This may change in future releases.

docs/code-quality/C26440.md

@@ -23,10 +23,10 @@ If code is not supposed to cause any exceptions, it should be marked as such by
 
 ## Remarks
 - A function is considered non-throwing if:
-  -  it has no explicit throw statements;
-  -  function calls in its body, if any, invoke only functions that unlikely to throw: constexpr or functions marked with any exception specification which entails non-throwing behavior (this includes some non-standard specifications).
-  -  Non-standard and outdated specifiers like throw() or declspec(nothrow) are not equivalent to ‘noexcept’.
-  -  Explicit specifiers noexcept(false) and noexcept(true) are respected appropriately.
-  -  Functions marked as constexpr are not supposed to cause exceptions and are not analyzed.
-  -  The rule also applies to lambda expressions.
-  -  The logic doesn’t consider recursive calls as potentially non-throwing. This may change in the future.
+  - it has no explicit throw statements;
+  - function calls in its body, if any, invoke only functions that unlikely to throw: constexpr or functions marked with any exception specification which entails non-throwing behavior (this includes some non-standard specifications).
+  - Non-standard and outdated specifiers like throw() or declspec(nothrow) are not equivalent to ‘noexcept’.
+  - Explicit specifiers noexcept(false) and noexcept(true) are respected appropriately.
+  - Functions marked as constexpr are not supposed to cause exceptions and are not analyzed.
+  - The rule also applies to lambda expressions.
+  - The logic doesn’t consider recursive calls as potentially non-throwing. This may change in the future.