Merge pull request #5946 from MicrosoftDocs/FromPublicMasterBranch

Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main)

Author: v-alje

docs/code-quality/c26409.md

@@ -1,10 +1,9 @@
 ---
-description: "Learn more about CppCoreCheck rule C26409: avoid explicit new and delete."
 title: Warning C26409
+description: "Learn more about CppCoreCheck rule C26409: avoid explicit new and delete."
 ms.date: 12/14/2020
 f1_keywords: ["C26409", "NO_NEW_DELETE"]
 helpviewer_keywords: ["C26409"]
-ms.assetid: a3b3a229-d566-4be3-bd28-2876ccc8dc37
 ---
 # Warning C26409
 
@@ -13,7 +12,7 @@ ms.assetid: a3b3a229-d566-4be3-bd28-2876ccc8dc37
 Even if code is clean of calls to `malloc` and `free`, we still suggest that you consider better options than explicit use of operators [`new` and `delete`](../cpp/new-and-delete-operators.md).
 
 **C++ Core Guidelines**:\
-[R.11: Avoid calling new and delete explicitly](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-explicitly)
+[R.11: Avoid calling `new` and `delete` explicitly](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-explicitly)
 
 The ultimate fix is to use smart pointers and appropriate factory functions, such as [`std::make_unique`](../standard-library/memory-functions.md#make_unique).
 

docs/code-quality/c26414.md

@@ -4,14 +4,13 @@ description: "Reference for Visual Studio C++ Core Guidelines code analysis warn
 ms.date: 01/29/2020
 f1_keywords: ["C26414", "RESET_LOCAL_SMART_PTR"]
 helpviewer_keywords: ["C26414"]
-ms.assetid: dd875d0c-6752-4491-a533-3e8831795fbc
 ---
 # Warning C26414
 
 > "Move, copy, reassign or reset a local smart pointer."
 
 **C++ Core Guidelines**:\
-[R.5: Prefer scoped objects, don't heap-allocate unnecessarily](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-scoped)
+[R.5: Prefer scoped objects, don't heap-allocate unnecessarily](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r5-prefer-scoped-objects-dont-heap-allocate-unnecessarily)
 
 Smart pointers are convenient for dynamic resource management, but they're not always necessary. For example, it may be easier and more efficient to manage a local dynamic buffer by using a standard container. You may not need dynamic allocation at all for single objects, for example, if they never outlive their creator function. They can be replaced with local variables. Smart pointers become handy when a scenario requires a change of ownership. For example, when you reassign a dynamic resource multiple times, or in multiple paths. They're also useful for resources obtained from external code. And, when smart pointers are used to extend the lifetime of a resource.
 

docs/code-quality/c26432.md

@@ -4,14 +4,13 @@ description: "Microsoft C++ Code Analysis warning C26432 for the C++ Core Guidel
 ms.date: 11/15/2017
 f1_keywords: ["C26432", "DEFINE_OR_DELETE_SPECIAL_OPS"]
 helpviewer_keywords: ["C26432"]
-ms.assetid: f587b05a-5c69-4176-baa6-fcb79d228b24
 ---
 # Warning C26432
 
 > `If you define or delete any default operation in the type 'type-name', define or delete them all (c.21).`
 
 **C++ Core Guidelines**:\
-[C.21: If you define or =delete any default operation, define or =delete them all](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all)
+[C.21: If you define or `=delete` any copy, move, or destructor function, define or `=delete` them all](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-copy-move-or-destructor-function-define-or-delete-them-all)
 
 Special operations such as constructors are assumed to alter the behavior of types so they rely more on language mechanisms to automatically enforce specific scenarios. The canonical example is resource management. If you explicitly define, default, or delete any of these special operations, it signals you want to avoid any special handling of a type. It's inconsistent to leave the other operations unspecified, that is, implicitly defined as deleted by the compiler.
 

docs/code-quality/c26437.md

@@ -4,14 +4,13 @@ description: "Learn more about: Warning C26437 DONT_SLICE"
 ms.date: 05/17/2023
 f1_keywords: ["C26437", "DONT_SLICE"]
 helpviewer_keywords: ["C26437"]
-ms.assetid: ed2f55bc-a6d8-4cc4-8069-5c96e581a96a
 ---
 # Warning C26437
 
 > Do not slice.
 
 **C++ Core Guidelines**:
-[ES.63: Don't slice](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-slice)
+[ES.63: Don't slice](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es63-dont-slice)
 
 The language allows [slicing](https://en.wikipedia.org/wiki/Object_slicing) and can be viewed as a special case of a dangerous implicit cast. Even if it's done intentionally and doesn't lead to immediate issues, it's still highly discouraged. It makes code harder to change, by forcing extra requirements on related data types. It's especially true if types are polymorphic or involve resource management.
 

docs/code-quality/c26439.md

@@ -4,13 +4,12 @@ description: CppCoreCheck rule C26439 that enforces C++ Core Guidelines F.6
 ms.date: 05/17/2023
 f1_keywords: ["C26439", "SPECIAL_NOEXCEPT"]
 helpviewer_keywords: ["C26439"]
-ms.assetid: 9df2a1b0-ea94-4884-9d28-c1522ec33a1b
 ---
 # Warning C26439
 
 > This kind of function may not throw. Declare it 'noexcept'.
 
-[**C++ Core Guidelines** F.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-noexcept): If your function must not throw, declare it `noexcept`
+[F.6: If your function must not throw, declare it `noexcept`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept)
 
 Some operations should never throw exceptions. Their implementations should be reliable and should handle possible errors conditions gracefully. They shouldn't use exceptions to indicate failure. This rule flags cases where such operations aren't explicitly marked as `noexcept`, which means that they may throw exceptions and consumers can't make assumptions about its reliability.
 
@@ -63,5 +62,5 @@ struct S
 
 ## See also
 
-[C26455](./c26455.md)\
-[**C++ Core Guidelines** F.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-noexcept)
+[C26455](c26455.md)\
+[F.6: If your function must not throw, declare it `noexcept`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept)

docs/code-quality/c26441.md

@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26441"]
 
 ## C++ Core Guidelines
 
-[CP.44](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp44-remember-to-name-your-lock_guards-and-unique_locks): Remember to name your `lock_guard`s and `unique_lock`s
+[CP.44: Remember to name your `lock_guard`s and `unique_lock`s](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp44-remember-to-name-your-lock_guards-and-unique_locks)
 
 ## Remarks
 

docs/code-quality/c26444.md

@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26444"]
 
 ## C++ Core Guidelines
 
-[ES.84: Don't (try to) declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-noname)
+[ES.84: Don't try to declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es84-dont-try-to-declare-a-local-variable-with-no-name)
 
 An unnamed variable declaration creates a temporary object that is discarded at the end of the statement. Such temporary objects with nontrivial behavior may point to either inefficient code that allocates and immediately throws away resources or to the code that unintentionally ignores nonprimitive data. Sometimes it may also indicate plainly wrong declaration.
 
@@ -46,4 +46,4 @@ void Foo()
 ## See also
 
 [C26441](C26441.md)\
-[ES.84: Don't (try to) declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-noname)
+[ES.84: Don't try to declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es84-dont-try-to-declare-a-local-variable-with-no-name)

docs/code-quality/c26449.md

@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26449"]
 
 > `gsl::span` or `std::string_view` created from a temporary will be invalid when the temporary is invalidated (gsl.view)
 
-C++ Core Guidelines: [GSL.view: Views](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#SS-views).
+C++ Core Guidelines: [GSL.view: Views](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#gslview-views).
 
 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). 
 

docs/code-quality/c26450.md

@@ -47,4 +47,4 @@ long long multiply()
 [C26452](c26452.md)\
 [C26453](c26453.md)\
 [C26454](c26454.md)\
-[ES.103: Don't overflow](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-overflow)
+[ES.103: Don't overflow](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es103-dont-overflow)

docs/code-quality/c26452.md

@@ -41,5 +41,5 @@ unsigned long long combine(unsigned lo, unsigned hi)
 [C26451](c26451.md)\
 [C26453](c26453.md)\
 [C26454](c26454.md)\
-[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned)\
-[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed)
+[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es101-use-unsigned-types-for-bit-manipulation)\
+[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es102-use-signed-types-for-arithmetic)