Fix URLs to C++ Core Guidelines

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).
 

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://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#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://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#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://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#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
 

docs/code-quality/c26414.md

@@ -10,7 +10,7 @@ helpviewer_keywords: ["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#r5-prefer-scoped-objects-dont-heap-allocate-unnecessarily)
+[R.5: Prefer scoped objects, don't heap-allocate unnecessarily](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-scoped)
 
 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/c26415.md

@@ -11,7 +11,7 @@ ms.assetid: 4165f70a-78ae-4a03-b256-c4bd74b02d09
 > Smart pointer parameter is used only to access contained pointer. Use T* or T& instead.
 
 **C++ Core Guidelines**:
-[R.30](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r30-take-smart-pointers-as-parameters-only-to-explicitly-express-lifetime-semantics): Take smart pointers as parameters only to explicitly express lifetime semantics
+[R.30](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-smartptrparam): Take smart pointers as parameters only to explicitly express lifetime semantics
 
 Using a smart pointer type to pass data to a function indicates that the target function needs to manage the lifetime of the contained object. However, say the function only uses the smart pointer to access the contained object and never actually calls any code that may lead to its deallocation (that is, never affects its lifetime). Then there's usually no need to complicate the interface with smart pointers. A plain pointer or reference to the contained object is preferred.
 

docs/code-quality/c26416.md

@@ -11,7 +11,7 @@ ms.assetid: f158207b-45cf-44cf-8e4b-b5b75b56ea0e
 > Shared pointer parameter is passed by rvalue reference. Pass by value instead.
 
 **C++ Core Guidelines**:
-[R.34](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r34-take-a-shared_ptrwidget-parameter-to-express-that-a-function-is-part-owner): Take a shared_ptr\<widget> parameter to express that a function is part owner
+[R.34](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-sharedptrparam-owner): Take a shared_ptr\<widget> parameter to express shared ownership
 
 Passing a shared pointer by rvalue reference is rarely necessary. Unless it's an implementation of move semantics for a shared pointer type itself, shared pointer objects can be safely passed by value. Using rvalue reference may be also an indication that unique pointer is more appropriate since it clearly transfers unique ownership from caller to callee.
 

docs/code-quality/c26417.md

@@ -11,7 +11,7 @@ ms.assetid: 0e09fcc6-f9eb-4404-b51e-5815705c6afb
 > Shared pointer parameter is passed by reference and not reset or reassigned. Use T* or T& instead.
 
 **C++ Core Guidelines**:
-[R.35](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r35-take-a-shared_ptrwidget-parameter-to-express-that-a-function-might-reseat-the-shared-pointer): Take a shared_ptr\<widget>& parameter to express that a function might reseat the shared pointer
+[R.35](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-sharedptrparam): Take a shared_ptr\<widget>& parameter to express that a function might reseat the shared pointer
 
 Passing shared pointers by reference may be useful in scenarios where called code updates the target of the smart pointer object, and its caller expects to see such updates. Using a reference solely to reduce costs of passing a shared pointer is questionable. If called code only accesses the target object and never manages its lifetime, it's safer to pass a raw pointer or reference, rather than to expose resource management details.
 

docs/code-quality/c26418.md

@@ -11,7 +11,7 @@ ms.assetid: d2c84a40-8a5d-4018-92c2-6498cdd9b541
 > Shared pointer parameter is not copied or moved. Use T* or T& instead.
 
 **C++ Core Guidelines**:
-[R.36](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r36-take-a-const-shared_ptrwidget-parameter-to-express-that-it-might-retain-a-reference-count-to-the-object-): Take a const shared_ptr\<widget>& parameter to express that it might retain a reference count to the object
+[R.36](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-sharedptrparam-const): Take a const shared_ptr\<widget>& parameter to express that it might retain a reference count to the object
 
 If a shared pointer parameter is passed by value or by reference to a constant object, the function is expected to take control of the target object's lifetime without affecting the caller. The code should either copy or move the shared pointer parameter to another shared pointer object, or pass it along to other code by invoking functions that accept shared pointers. Otherwise, a plain pointer or reference may be feasible.
 

docs/code-quality/c26426.md

@@ -12,7 +12,7 @@ ms.assetid: 6fb5f6d2-b097-47f8-8b49-f2fd4e9bef0e
 
 ## C++ Core Guidelines
 
-[I.22](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i22-avoid-complex-initialization-of-global-objects): Avoid complex initialization of global objects
+[I.22](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-global-init): Avoid complex initialization of global objects
 
 The order of execution of initializers for global objects may be inconsistent or undefined, which can lead to issues that are hard to reproduce and investigate. To avoid such problems, global initializers shouldn't depend on external code that's executed at run time, and that may depend on data that's not yet initialized. This rule flags cases where global objects call functions to obtain their initial values.
 

docs/code-quality/c26427.md

@@ -11,7 +11,7 @@ ms.assetid: 8fb95a44-8704-45b1-bc55-eccd59b1db2f
 > Global initializer accesses extern object '*symbol*' (i.22)
 
 **C++ Core Guidelines**:
-[I.22](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i22-avoid-complex-initialization-of-global-objects): Avoid complex initialization of global objects
+[I.22](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-global-init): Avoid complex initialization of global objects
 
 Global objects may be initialized in an inconsistent or undefined order, which means that interdependency between them is risky and should be avoided. This guideline is applicable when initializers refer to another object that's considered to be **`extern`**.
 

docs/code-quality/c26429.md

@@ -11,7 +11,7 @@ ms.assetid: 4e1c74d5-7307-436c-927b-f74ae863282c
 > Symbol is never tested for nullness, it can be marked as `gsl::not_null`.
 
 **C++ Core Guidelines**:
-[F.23](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#f23-use-a-not_nullt-to-indicate-that-null-is-not-a-valid-value): Use a `not_null<T>` to indicate that "null" isn't a valid value
+[F.23](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-nullptr): Use a `not_null<T>` to indicate that "null" is not a valid value
 
 It's a common practice to use asserts to enforce assumptions about the validity of pointer values. The problem is, asserts don't expose assumptions through the interface (such as in return types or parameters). Asserts are also harder to maintain and keep in sync with other code changes. The recommendation is to use `gsl::not_null` from the Guidelines Support Library to mark resources that should never have a null value. The rule `USE_NOTNULL` helps to identify places that omit checks for null and hence can be updated to use `gsl::not_null`.