Fix warnings.

Author: Xazax-hun

docs/code-quality/c26441.md

@@ -19,7 +19,7 @@ The standard library provides locks to help control concurrent access to resourc
 
 This diagnostic only analyzes the standard lock types `std::scoped_lock`, `std::unique_lock`, and `std::lock_guard`. Warning [C26444](c26444.md) covers other unnamed RAII types.
 
-The analyzer only analyzes simple calls to constructors. More complex initializer expressions may lead to inaccurate results in the form of missed warnings. Locks passed as arguments to function calls or returned as results of function calls are ignored because the analysis tool is unable to determine if those locks are deliberately trying to protect that function call or if they should be extended. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. You can also annotate constructors with `[[nodiscard]]` to avoid unnamed objects of that type. The analyzer ignores locks created as temporaries but assigned to named references to extend their lifetime.
+The analyzer only analyzes simple calls to constructors. More complex initializer expressions may lead to inaccurate results in the form of missed warnings. The analyzer ignores locks passed as arguments to function calls or returned from function calls. It is unable to determine if those locks are deliberately trying to protect that function call or if they should be extended. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. You can also annotate constructors with `[[nodiscard]]` to avoid unnamed objects of that type. The analyzer ignores locks created as temporaries but assigned to named references to extend their lifetime.
 
 Code analysis name: `NO_UNNAMED_GUARDS`
 

docs/code-quality/c26444.md

@@ -13,12 +13,12 @@ helpviewer_keywords: ["C26444"]
 
 [ES.84: Don't (try to) declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-noname)
 
-Unnamed (that is, temporary) objects with non-trivial behavior may point to either (a) inefficient code that allocates and immediately throws away resources or (b) to the code that unintentionally ignores non-primitive data. Sometimes it may also indicate plainly wrong declaration.
+Unnamed temporary objects with nontrivial behavior may point to either (a) inefficient code that allocates and immediately throws away resources or (b) to the code that unintentionally ignores nonprimitive data. Sometimes it may also indicate plainly wrong declaration.
 
 ## Remarks
 
-- This rule detects types with non-trivial destructors. Keep in mind that destructors can be compiler generated.
-- The warning can flag code that invokes either a non-trivial constructor of a RAII type.
+- This rule detects types with nontrivial destructors. Keep in mind that destructors can be compiler generated.
+- The warning can flag code that invokes either a nontrivial constructor of a RAII type.
 - The logic skips temporaries if they're used in higher-level expressions. One example is temporaries that are passed as arguments or used to invoke a function.
 
 Code analysis name: `NO_UNNAMED_RAII_OBJECTS`

docs/code-quality/c26449.md

@@ -1,7 +1,7 @@
 ---
 title: Warning C26449
 description: "Learn more about: Warning C26449 NO_SPAN_FROM_TEMPORARY"
-ms.date: 05/11/2024
+ms.date: 05/11/2023
 f1_keywords: ["C26449", "NO_SPAN_FROM_TEMPORARY"]
 helpviewer_keywords: ["C26449"]
 ---
@@ -13,7 +13,7 @@ C++ Core Guidelines: [GSL.view: Views](https://isocpp.github.io/CppCoreGuideline
 
 Spans and views are convenient and lightweight types that allow you to reference memory buffers. But they must be used carefully: while their interface looks similar to standard containers, their behavior is more like the behavior of pointers and references. They don't own data and must never be constructed from temporary buffers. This check focuses on cases where source data is temporary, while a span or view isn't. This rule can help to avoid subtle but dangerous mistakes made when legacy code gets modernized and adopts spans or views. There's another check that handles a slightly different scenario involving span references: [C26445 NO_SPAN_REF](c26445.md). 
 
-Consider using [C26815](c26815.md) and [C26816](c26816.md). Those are more general versions of this check.
+Consider using [C26815](c26815.md) and [C26816](c26816.md). Those warnings are more general versions of this warning.
 
 ## Remarks
 
@@ -53,7 +53,7 @@ void run_batch()
 }
 ```
 
-To fix the issue, make sure the view is created from an object that lives at least as long as the view itself. Sometimes this can be achieved by copying the data, other times some APIs need to be redesigned.
+To fix the issue, make sure the view is created from an object that lives at least as long as the view itself. Sometimes a solution can be achieved by copying the data, other times some APIs need to be redesigned.
 
 ## See also
 [C26815](c26815.md)\

docs/code-quality/c26453.md

@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26453"]
 
 ## Remarks
 
-This warning indicates the code left shifts a negative signed integral value, which is non-portable and triggers implementation defined behavior.
+This warning indicates the code left shifts a negative signed integral value, which is nonportable and triggers implementation defined behavior.
 
 Code analysis name: `LEFTSHIFT_NEGATIVE_SIGNED_NUMBER`
 

docs/code-quality/c26495.md

@@ -13,7 +13,7 @@ helpviewer_keywords: ["C26495"]
 
 A member variable isn't initialized by a constructor or by an initializer. Make sure all variables are initialized by the end of construction. For more information, see C++ Core Guidelines [Type.6](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#SS-type) and [C.48](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers).
 
-This check is intra-procedural. Whenever there is a function call to a non-const member function, the check assumes that this member function will initialize all of the members. This heuristic can result in missed errors and is in place to avoid false positive results. Moreover, when a member is passed by non-const reference to a function, the check assumes that the function will initialize the member.
+This check is intra-procedural. Whenever there is a function call to a nonconst member function, the check assumes that this member function initializes all of the members. This heuristic can result in missed errors and is in place to avoid false positive results. Moreover, when a member is passed by nonconst reference to a function, the check assumes that the function initializes the member.
 
 Code analysis name: `MEMBER_UNINIT`
 

docs/code-quality/c26810.md

@@ -17,7 +17,7 @@ Code analysis name: `COROUTINES_USE_AFTER_FREE_CAPTURE`
 
 ## Example
 
-The following code will generate C26810.
+The following code generates C26810.
 
 ```cpp
 #include <experimental/generator>

docs/code-quality/c26811.md

@@ -11,13 +11,13 @@ helpviewer_keywords: ["C26811"]
 
 ## Remarks
 
-Warning C26811 is triggered when a variables might be used after its lifetime ended in a resumed coroutine.
+Warning C26811 is triggered when a variable might be used after its lifetime ended in a resumed coroutine.
 
 Code analysis name: `COROUTINES_USE_AFTER_FREE_PARAM`
 
 ## Example
 
-The following code will generate C26811.
+The following code generates C26811.
 
 ```cpp
 #include <experimental/generator>

docs/code-quality/c26819.md

@@ -17,7 +17,7 @@ For more information, see [ES.78: Don't rely on implicit fallthrough in `switch`
 
 ## Example
 
-In this sample, implicit fallthrough occurs from a non-empty switch case into a following case.
+In this sample, implicit fallthrough occurs from a nonempty switch case into a following case.
 
 ```cpp
 void fn1();