Merge pull request #6033 from MicrosoftDocs/FromPublicMasterBranch

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

Author: Albertyang0

docs/build/toc.yml

@@ -552,7 +552,7 @@ items:
                       href: ../build/reference/fp-name-dot-pch-file.md
                     - name: /FR, /Fr (Create .Sbr file)
                       href: ../build/reference/fr-fr-create-dot-sbr-file.md
-                    - name: /FU (Name forced
+                    - name: "/FU (Name forced #using file)"
                       href: ../build/reference/fu-name-forced-hash-using-file.md
                     - name: /Fx (Merge injected code)
                       href: ../build/reference/fx-merge-injected-code.md

docs/code-quality/c26400.md

@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26400"]
 
 ## Remarks
 
-This check helps to enforce the *rule I.11: Never transfer ownership by a raw pointer (T\*), which is a subset of the rule *R.3: A raw pointer (a T\*) is non-owning*. Specifically, it warns on any call to `operator new`, which saves its result in a variable of raw pointer type. It also warns on calls to functions that return `gsl::owner<T>` if their results are assigned to raw pointers. The idea is that you should clearly state ownership of memory resources. For more information, see the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r-resource-management).
+This check helps to enforce the *rule I.11: Never transfer ownership by a raw pointer (T\*), which is a subset of the rule *R.3: A raw pointer (a T\*) is non-owning*. Specifically, it warns on any call to `operator new`, which saves its result in a variable of raw pointer type. It also warns on calls to functions that return `gsl::owner<T>` if their results are assigned to raw pointers. The idea is that you should clearly state ownership of memory resources. For more information, see the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource).
 
 The easiest way to fix this warning is to use **`auto`** declaration if the resource is assigned immediately at the variable declaration. If this fix isn't possible, then we suggest that you use the type `gsl::owner<T>`. The **`auto`** declarations initialized with operator **`new`** are "owners" because we assume that the result of any allocation is implicitly an owner pointer. We transfer this assumption to the **`auto`** variable and treat it as `owner<T>`.
 

docs/code-quality/c26401.md

@@ -20,7 +20,7 @@ Code analysis name: `DONT_DELETE_NON_OWNER`
 
 ## See also
 
-[C++ Core Guidelines I.11](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i11-never-transfer-ownership-by-a-raw-pointer-t-or-reference-t)
+[C++ Core Guidelines I.11](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-raw)
 
 ## Examples
 

docs/code-quality/c26402.md

@@ -12,7 +12,7 @@ ms.assetid: b9d3d398-697a-4a5d-8bfe-9c667dffb90b
 
 ## Remarks
 
-To avoid confusion about whether a pointer owns an object, a function that returns a movable object should allocate it on the stack. It should then return the object by value instead of returning a heap-allocated object. If pointer semantics are required, return a smart pointer instead of a raw pointer. For more information, see [C++ Core Guidelines R.3](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rr-ptr): *Warn if a function returns an object that was allocated within the function but has a move constructor. Suggest considering returning it by value instead.*
+To avoid confusion about whether a pointer owns an object, a function that returns a movable object should allocate it on the stack. It should then return the object by value instead of returning a heap-allocated object. If pointer semantics are required, return a smart pointer instead of a raw pointer. For more information, see [C++ Core Guidelines R.3](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr): *Warn if a function returns an object that was allocated within the function but has a move constructor. Suggest considering returning it by value instead.*
 
 ## Example
 

docs/code-quality/c26403.md

@@ -12,7 +12,7 @@ ms.assetid: 7e14868d-df86-4df3-98d3-71b1e80ba14e
 
 Owner pointers are like unique pointers: they own a resource exclusively, and manage release of the resource, or its transfers to other owners. This check validates that a local owner pointer properly maintains its resource through all execution paths in a function. If the resource wasn't transferred to another owner, or wasn't explicitly release, the checker warns, and points to the declaration of the pointer variable.
 
-For more information, see the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r-resource-management).
+For more information, see the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource).
 
 ## Remarks
 

docs/code-quality/c26405.md

@@ -12,7 +12,7 @@ ms.assetid: 2034d961-3ec5-4184-bbef-aa792e4c03c0
 
 ## Remarks
 
-If an owner pointer already points to a valid memory buffer, it must not be assigned to another value without releasing its current resource first. Such assignment may lead to a resource leak even if the resource address is copied into some raw pointer (because raw pointers shouldn't release resources). For more information, see the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r3-a-raw-pointer-a-t-is-non-owning).
+If an owner pointer already points to a valid memory buffer, it must not be assigned to another value without releasing its current resource first. Such assignment may lead to a resource leak even if the resource address is copied into some raw pointer (because raw pointers shouldn't release resources). For more information, see the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr).
 
 Code analysis name: `DONT_ASSIGN_TO_VALID`
 

docs/code-quality/c26406.md

@@ -10,7 +10,7 @@ ms.assetid: 02fb8e23-1989-4e24-a5a5-e30f71d00325
 
 > Do not assign a raw pointer to an `owner<T>` (r.3)
 
-This warning enforces R.3 from the C++ Core Guidelines. For more information, see [C++ Core Guidelines R.3](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r3-a-raw-pointer-a-t-is-non-owning).
+This warning enforces R.3 from the C++ Core Guidelines. For more information, see [C++ Core Guidelines R.3](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr).
 
 ## Remarks
 

docs/code-quality/c26407.md

@@ -10,7 +10,7 @@ ms.assetid: 5539907a-bfa0-40db-82a6-b860c97209e1
 
 > Prefer scoped objects, don't heap-allocate unnecessarily (r.5)
 
-To avoid unnecessary use of pointers, we try to detect common patterns of local allocations. For example, we detect when the result of a call to operator **`new`** is stored in a local variable and later explicitly deleted. This check supports the [C++ Core Guidelines rule R.5](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r5-prefer-scoped-objects-dont-heap-allocate-unnecessarily): *Prefer scoped objects, don't heap-allocate unnecessarily*. To fix the issue, use an RAII type instead of a raw pointer, and allow it to deal with resources. Obviously, it isn't necessary to create a wrapper type to allocate a single object. Instead, a local variable of the object's type would work better.
+To avoid unnecessary use of pointers, we try to detect common patterns of local allocations. For example, we detect when the result of a call to operator **`new`** is stored in a local variable and later explicitly deleted. This check supports the [C++ Core Guidelines rule R.5](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-scoped): *Prefer scoped objects, don't heap-allocate unnecessarily*. To fix the issue, use an RAII type instead of a raw pointer, and allow it to deal with resources. Obviously, it isn't necessary to create a wrapper type to allocate a single object. Instead, a local variable of the object's type would work better.
 
 ## Remarks
 

docs/code-quality/c26408.md

@@ -22,7 +22,7 @@ Code analysis name: `NO_MALLOC_FREE`
 
 ## See also
 
-[C++ Core Guidelines R.10](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r10-avoid-malloc-and-free)
+[C++ Core Guidelines R.10](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-mallocfree)
 
 ## Example
 

docs/code-quality/c26409.md

@@ -12,7 +12,7 @@ helpviewer_keywords: ["C26409"]
 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#Rr-newdelete)
 
 The ultimate fix is to use smart pointers and appropriate factory functions, such as [`std::make_unique`](../standard-library/memory-functions.md#make_unique).