Merge pull request MicrosoftDocs#4565 from corob-msft/learn/corob/ca-acrolinx-3

Fix Code Analysis warning publishing issues

Author: AnnaMHuff

docs/code-quality/c26138.md

@@ -2,17 +2,19 @@
 description: "Learn more about: Warning C26138"
 title: Warning C26138
 ms.date: 01/14/2019
-f1_keywords: ["C26138"]
+f1_keywords: ["C26138", "SUSPENDED_WITH_LOCK"]
 helpviewer_keywords: ["C26138"]
-author: sunnychatterjee
-ms.author: sunnych
 ---
 # Warning C26138
 
 > Suspending a coroutine while holding lock '*lock*'.
 
+## Remarks
+
 Warning C26138 warns when a coroutine is suspended while holding a lock. In general, we can't know how long will a coroutine remain in the suspended state so this pattern may result in longer critical sections than expected.
 
+Code analysis name: `SUSPENDED_WITH_LOCK`
+
 ## Examples
 
 The following code will generate C26138.

docs/code-quality/c26433.md

@@ -4,11 +4,10 @@ title: Warning C26433
 ms.date: 01/18/2017
 f1_keywords: ["C26433", "OVERRIDE_EXPLICITLY"]
 helpviewer_keywords: ["C26433"]
-dev_langs: ["C++"]
 ---
 # Warning C26433
 
-Function should be marked with `override`
+> Function should be marked with `override`
 
 ## C++ Core Guidelines
 
@@ -24,6 +23,8 @@ The rule doesn't flag functions explicitly marked as `final`, which is itself a
 
 Warnings show up on function definitions, not declarations. It may be confusing, since definitions don't have virtual specifiers, but the warning is still correct.
 
+Code analysis name: `OVERRIDE_EXPLICITLY`
+
 ## Example:  Implicit overriding
 
 ```cpp

docs/code-quality/c26435.md

@@ -4,7 +4,6 @@ title: Warning C26435
 ms.date: 01/18/2017
 f1_keywords: ["C26435", "SINGLE_VIRTUAL_SPECIFICATION"]
 helpviewer_keywords: ["C26435"]
-dev_langs: ["C++"]
 ---
 # Warning C26435
 
@@ -25,6 +24,8 @@ To improve readability, the kind of virtual behavior should be stated clearly an
 - This rule skips destructors since they have special rules regarding virtuality.
 - Warnings show up on function definitions, not declarations. It may be confusing, since definitions don't have virtual specifiers, but the warning is still appropriate.
 
+Code analysis name: `SINGLE_VIRTUAL_SPECIFICATION`
+
 ## Example: Redundant specifier
 
 ```cpp

docs/code-quality/c26443.md

@@ -3,12 +3,11 @@ title: Warning C26443
 ms.date: 01/18/2017
 f1_keywords: ["C26443", "NO_EXPLICIT_DTOR_OVERRIDE"]
 helpviewer_keywords: ["C26443"]
-dev_langs: ["C++"]
 description: Warning C26443 Rule concerning overriding destructors
 ---
 # Warning C26443
 
-"Overriding destructor should not use explicit 'override' or 'virtual' specifiers."
+> Overriding destructor should not use explicit 'override' or 'virtual' specifiers.
 
 This warning was removed in Visual Studio 16.8 to reflect [changes to C.128 in the C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/pull/1448).
 
@@ -24,6 +23,8 @@ The current consensus on the Core Guidelines is to exclude destructors from the
 - Destructors can still use the 'final' specifier because of its special semantics.
 - Warnings show up on function definitions, not declarations. It may be confusing, since definitions don't have virtual specifiers, but the warning is still appropriate.
 
+Code analysis name: `NO_EXPLICIT_DTOR_OVERRIDE`
+
 ## Example: Explicit 'override'
 
 ```cpp

docs/code-quality/c26444.md

@@ -4,11 +4,10 @@ title: Warning C26444
 ms.date: 01/18/2017
 f1_keywords: ["C26444", "NO_UNNAMED_RAII_OBJECTS"]
 helpviewer_keywords: ["C26444"]
-dev_langs: ["C++"]
 ---
 # Warning C26444
 
-Avoid unnamed objects with custom construction and destruction.
+> Avoid unnamed objects with custom construction and destruction.
 
 ## C++ Core Guidelines
 
@@ -23,6 +22,8 @@ Unnamed (that is, temporary) objects with non-trivial behavior may point to eith
 - 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.
 - The standard library implementation may have different versions of destruction logic for some types (for example, containers). This can produce noisy warnings on debug builds because it's customary to ignore iterators returned from calls like [`std::vector::insert`](../standard-library/vector-class.md#insert). While such warnings aren't actionable in most cases, they're legitimate in pointing to the place where some non-obvious work is done in temporary objects.
 
+Code analysis name: `NO_UNNAMED_RAII_OBJECTS`
+
 ## Example: Ignored call result
 
 ```cpp

docs/code-quality/c26450.md

@@ -2,16 +2,21 @@
 description: "Learn more about: Arithmetic overflow: '%operator%' operation causes overflow at compile time. Use a wider type to store the operands"
 title: Warning C26450
 ms.date: 01/08/2017
-f1_keywords: ["C26450"]
+f1_keywords: ["C26450", "RESULT_OF_ARITHMETIC_OPERATION_PROVABLY_LOSSY"]
 helpviewer_keywords: ["C26450"]
-dev_langs: ["C++"]
 ---
-# Arithmetic overflow: '%operator%' operation causes overflow at compile time. Use a wider type to store the operands
+# Warning C26450
+
+>Arithmetic overflow: '*operator*' operation causes overflow at compile time. Use a wider type to store the operands (io.1)
+
+## Remarks
 
 This warning indicates that an arithmetic operation was provably lossy at compile time. It can be asserted when the operands are all compile-time constants. Currently, we check left shift, multiplication, addition, and subtraction operations for such overflows.
 
 Warning C4307 is a similar check in the Microsoft C++ compiler.
 
+Code analysis name: `RESULT_OF_ARITHMETIC_OPERATION_PROVABLY_LOSSY`
+
 ## Example 1
 
 ```cpp

docs/code-quality/c26451.md

@@ -2,20 +2,21 @@
 title: Warning C26451
 description: "Describes the causes of MSVC code analysis warning C26451, and shows how to fix it."
 ms.date: 07/15/2020
-f1_keywords: ["C26451"]
+f1_keywords: ["C26451", "RESULT_OF_ARITHMETIC_OPERATION_CAST_TO_LARGER_SIZE"]
 helpviewer_keywords: ["C26451"]
-dev_langs: ["C++"]
 ---
 # Warning C26451
 
-> Arithmetic overflow: Using operator '*operator*' on a *size-a* byte value and then casting the result to a *size-b* byte value. Cast the value to the wider type before calling operator '*operator*' to avoid overflow
+> Arithmetic overflow: Using operator '*operator*' on a *size-a* byte value and then casting the result to a *size-b* byte value. Cast the value to the wider type before calling operator '*operator*' to avoid overflow (io.2)
 
 This warning indicates incorrect behavior that results from integral promotion rules and types larger than the ones in which arithmetic is typically performed.
 
 ## Remarks
 
 Code analysis detects when an integral value gets shifted left, multiplied, added, or subtracted, and the result gets cast to a wider integral type. If the operation overflows the narrower integral type, then data is lost. You can prevent this loss by casting the value to a wider type before the arithmetic operation.
 
+Code analysis name: `RESULT_OF_ARITHMETIC_OPERATION_CAST_TO_LARGER_SIZE`
+
 ## Example 1
 
 The following code generates this warning:

docs/code-quality/c26452.md

@@ -2,16 +2,20 @@
 title: Warning C26452
 description: "Describes causes of MSVC Code analysis warning C26452, and how to fix the issue."
 ms.date: 07/15/2020
-f1_keywords: ["C26452"]
+f1_keywords: ["C26452", "SHIFT_COUNT_NEGATIVE_OR_TOO_BIG"]
 helpviewer_keywords: ["C26452"]
-dev_langs: ["C++"]
 ---
 # Warning C26452
 
-> Arithmetic overflow: Left shift count is negative or greater than or equal to the operand size, which is undefined behavior
+> Arithmetic overflow: Left shift count is negative or greater than or equal to the operand size, which is undefined behavior (io.3)
+
+## Remarks
 
 This warning indicates the shift count is negative, or greater than or equal to the number of bits in the shifted operand. Either case results in undefined behavior.
-C4293 is a similar check in the Microsoft C++ compiler.
+
+Warning C4293 is a similar check in the Microsoft C++ compiler.
+
+Code analysis name: `SHIFT_COUNT_NEGATIVE_OR_TOO_BIG`
 
 ## Example
 

docs/code-quality/c26453.md

@@ -2,16 +2,19 @@
 title: Warning C26453
 description: "Describes the causes of MSVC code analysis warning C26453, and shows how to fix it."
 ms.date: 07/15/2020
-f1_keywords: ["C26453"]
+f1_keywords: ["C26453", "LEFTSHIFT_NEGATIVE_SIGNED_NUMBER"]
 helpviewer_keywords: ["C26453"]
-dev_langs: ["C++"]
 ---
 # Warning C26453
 
-> Arithmetic overflow: Left shift of a negative signed number is undefined behavior
+> Arithmetic overflow: Left shift of a negative signed number is undefined behavior (io.4)
+
+## Remarks
 
 This warning indicates the code left shifts a negative signed integral value, which is non-portable and triggers implementation defined behavior.
 
+Code analysis name: `LEFTSHIFT_NEGATIVE_SIGNED_NUMBER`
+
 ## Example
 
 ```cpp

docs/code-quality/c26454.md

@@ -1,14 +1,19 @@
 ---
-description: "Learn more about: Arithmetic overflow: '%operator%' operation produces a negative unsigned result at compile time"
+description: "Learn more about: Arithmetic overflow: 'operator' operation produces a negative unsigned result at compile time"
 title: Warning C26454
 ms.date: 01/08/2017
-f1_keywords: ["C26454"]
+f1_keywords: ["C26454", "RESULT_OF_ARITHMETIC_OPERATION_NEGATIVE_UNSIGNED"]
 helpviewer_keywords: ["C26454"]
-dev_langs: ["C++"]
 ---
-# Arithmetic overflow: '%operator%' operation produces a negative unsigned result at compile time
+# Warning C26454
 
-  This warning indicates that the subtraction operation produces a negative result that was evaluated in an unsigned context, which can result in unintended overflows.
+> Arithmetic overflow: '*operator*' operation produces a negative unsigned result at compile time
+
+## Remarks
+
+This warning indicates that the subtraction operation produces a negative result that was evaluated in an unsigned context, which can result in unintended overflows.
+
+Code analysis name: `RESULT_OF_ARITHMETIC_OPERATION_NEGATIVE_UNSIGNED`
 
 ## Example
 

docs/code-quality/c26478.md

@@ -1,19 +1,21 @@
 ---
 description: "Learn more about: Warning C26478: Don't use std::move on constant variables. (es.56)"
-title: c26478
-keywords: c26478
+title: Warning C26478
 ms.date: 07/15/2019
-f1_keywords: ["C26478"]
+f1_keywords: ["C26478", "NO_MOVE_OP_ON_CONST"]
 helpviewer_keywords: ["C26478"]
-dev_langs: ["C++"]
 ---
 # Warning C26478
 
-> Don't use std::move on constant variables. (es.56)
+> Don't use `std::move` on constant variables. (es.56)
 
-This warning is to indicate that the use of std::move not consistent with how std::move is intended to be used.
+## Remarks
 
-When called on a const object, std::move returns a copy of the object, which is likely not the developer's intent.
+This warning is to indicate that the use of `std::move` not consistent with how `std::move` is intended to be used.
+
+When called on a `const` object, `std::move` returns a copy of the object, which is likely not the developer's intent.
+
+Code analysis name: `NO_MOVE_OP_ON_CONST`
 
 ## Example 1
 

docs/code-quality/c26800.md

@@ -2,16 +2,18 @@
 description: "Learn more about: Warning C26800"
 title: Warning C26800
 ms.date: 01/14/2019
-f1_keywords: ["C26800"]
+f1_keywords: ["C26800", "USE_OF_A_MOVED_FROM_OBJECT"]
 helpviewer_keywords: ["C26800"]
-author: sunnychatterjee
-ms.author: sunnych
 ---
 # Warning C26800
 
 > Use of a moved from object: '*object*'.
 
-Warning C26800 is triggered when variable is used after it has been moved from. A variable is considered moved from after it was passed to a function as rvalue reference. There are some legitimate exceptions for uses such as assignment, destruction, and some state resetting functions such as std::vector::clear.
+## Remarks
+
+Warning C26800 is triggered when variable is used after it has been moved from. A variable is considered moved from after it was passed to a function as rvalue reference. There are some legitimate exceptions for uses such as assignment, destruction, and some state resetting functions such as `std::vector::clear`.
+
+Code analysis name: `USE_OF_A_MOVED_FROM_OBJECT`
 
 ## Examples
 

docs/code-quality/c26810.md

@@ -2,17 +2,19 @@
 description: "Learn more about: Warning C26810"
 title: Warning C26810
 ms.date: 01/14/2019
-f1_keywords: ["C26810"]
+f1_keywords: ["C26810", "COROUTINES_USE_AFTER_FREE_CAPTURE"]
 helpviewer_keywords: ["C26810"]
-author: sunnychatterjee
-ms.author: sunnych
 ---
 # Warning C26810
 
 > Lifetime of captured variable '*var*' might end by the time the coroutine is resumed.
 
+## Remarks
+
 Warning C26810 is triggered when a memory region might be used after it went out of scope in a resumed coroutine.
 
+Code analysis name: `COROUTINES_USE_AFTER_FREE_CAPTURE`
+
 ## Example
 
 The following code will generate C26810.

docs/code-quality/c26811.md

@@ -2,17 +2,19 @@
 description: "Learn more about: Warning C26811"
 title: Warning C26811
 ms.date: 01/14/2019
-f1_keywords: ["C26811"]
+f1_keywords: ["C26811", "COROUTINES_USE_AFTER_FREE_PARAM"]
 helpviewer_keywords: ["C26811"]
-author: sunnychatterjee
-ms.author: sunnych
 ---
 # Warning C26811
 
 > Lifetime of the memory referenced by parameter '*var*' might end by the time the coroutine is resumed.
 
+## Remarks
+
 Warning C26811 is triggered when a memory region might be used after it went out of scope in a resumed coroutine.
 
+Code analysis name: `COROUTINES_USE_AFTER_FREE_PARAM`
+
 ## Example
 
 The following code will generate C26811.

docs/code-quality/c26812.md

@@ -1,17 +1,19 @@
 ---
 description: "Learn more about: Warning C26812"
-title: c26812
-keywords: c26812
+title: Warning C26812
 ms.date: 02/14/2022
-f1_keywords: ["C26812"]
+f1_keywords: ["C26812", "PreferScopedEnum"]
 helpviewer_keywords: ["C26812"]
-dev_langs: ["C++"]
 ---
 # Warning C26812
 
-> Prefer 'enum class' over 'enum' (Enum.3)
+> The enum type '*type-name*' is unscoped. Prefer 'enum class' over 'enum' (Enum.3)
 
-The `enum` type *type-name* is unscoped. Prefer `enum class` over `enum` (Enum.3)
+## Remarks
+
+Prefer `enum class` over `enum` to prevent pollution in the global namespace.
+
+Code analysis name: `PreferScopedEnum`
 
 ## Example
 

docs/code-quality/c26813.md

@@ -1,16 +1,20 @@
 ---
 description: "Learn more about: Warning C26813"
-title: c26813
+title: Warning C26813
 ms.date: 03/02/2022
-f1_keywords: ["C26813"]
+f1_keywords: ["C26813", "USE_BITWISE_AND_TO_CHEK_ENUM_FLAGS", "USE_BITWISE_AND_TO_CHECK_ENUM_FLAGS"]
 helpviewer_keywords: ["C26813"]
 ---
 # Warning C26813
 
 > Use 'bitwise and' to check if a flag is set
 
+## Remarks
+
 Most `enum` types with power of two member values are intended to be used as bit flags. As a result, you rarely want to compare these flags for equality. Instead, extract the bits you're interested in by using bitwise operations.
 
+Code analysis name: `USE_BITWISE_AND_TO_CHEK_ENUM_FLAGS`
+
 ## Example
 
 ```cpp