Replace generated IDs with explicit IDs

Also replaced some explicit IDs with more specific explicit IDs for Bounds.N and Type.N (to the specific rule, instead of the section containing the rule).

Author: mrotteveel

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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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/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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#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).
 

docs/code-quality/c26410.md

@@ -10,11 +10,11 @@ ms.assetid: d1547faf-96c6-48da-90f5-841154d0e878
 
 > The parameter '*parameter*' is a reference to const unique pointer, use `const T*` or `const T&` instead (r.32)
 
-Generally, references to const unique pointer are meaningless. They can safely be replaced by a raw reference or a pointer. This warning enforces [C++ Core Guidelines rule R.32](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r32-take-a-unique_ptrwidget-parameter-to-express-that-a-function-assumes-ownership-of-a-widget).
+Generally, references to const unique pointer are meaningless. They can safely be replaced by a raw reference or a pointer. This warning enforces [C++ Core Guidelines rule R.32](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-uniqueptrparam).
 
 ## Remarks
 
-- Unique pointer checks have rather broad criteria to identify smart pointers. The [C++ Core Guidelines rule R.31](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r31-if-you-have-non-std-smart-pointers-follow-the-basic-pattern-from-std): *If you have non-std smart pointers, follow the basic pattern from std describes the unique pointer and shared pointer concepts*. The heuristic is simple, but may lead to surprises: a smart pointer type is any type that defines either `operator->` or `operator*`. A copy-able type (shared pointer) must have either a public copy constructor or an overloaded assignment operator that deals with a non-Rvalue reference parameter.
+- Unique pointer checks have rather broad criteria to identify smart pointers. The [C++ Core Guidelines rule R.31](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-smart): *If you have non-std smart pointers, follow the basic pattern from std describes the unique pointer and shared pointer concepts*. The heuristic is simple, but may lead to surprises: a smart pointer type is any type that defines either `operator->` or `operator*`. A copy-able type (shared pointer) must have either a public copy constructor or an overloaded assignment operator that deals with a non-Rvalue reference parameter.
 
 - Template code may produce noisy warnings. Keep in mind that templates can be instantiated with various type parameters with different levels of indirection, including references. Some warnings may not be obvious and fixes may require some rework of templates (for example, explicit removal of reference indirection). If template code is intentionally generic, the warning can be suppressed.
 

docs/code-quality/c26411.md

@@ -10,7 +10,7 @@ ms.assetid: 5134e51e-8b92-4ee7-94c3-022e318a0e24
 
 > The parameter '*parameter*' is a reference to unique pointer and it is never reassigned or reset, use `T*` or `T&` instead (r.33)
 
-When you pass a unique pointer to a function by reference, it implies that its resource may be released or transferred inside the function. If the function uses its parameter only to access the resource, it's safe to pass a raw pointer or a reference. For more information, see [C++ Core Guidelines rule R.33](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r33-take-a-unique_ptrwidget-parameter-to-express-that-a-function-reseats-thewidget): *Take a unique_ptr\<widget\>& parameter to express that a function reseats the widget*.
+When you pass a unique pointer to a function by reference, it implies that its resource may be released or transferred inside the function. If the function uses its parameter only to access the resource, it's safe to pass a raw pointer or a reference. For more information, see [C++ Core Guidelines rule R.33](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-reseat): *Take a unique_ptr\<widget\>& parameter to express that a function reseats the widget*.
 
 ## Remarks