Merge pull request MicrosoftDocs#3057 from MicrosoftDocs/FromPublicMasterBranch

Colin Robertson · web-flow · commit e5ea538b3a72 · 2020-08-19T05:39:23.000-07:00
Confirm merge from FromPublicMasterBranch to master to sync with https://github.com/MicrosoftDocs/cpp-docs (branch master)
diff --git a/docs/build/reference/msbuild-visual-cpp-overview.md b/docs/build/reference/msbuild-visual-cpp-overview.md
@@ -16,15 +16,15 @@ By default, the primary Visual Studio support files are located in the following
 
 ### Visual Studio 2019
 
-- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\VCTargets\\
+- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\
 
   Contains the primary target files (.targets) and property files (.props) that are used by the targets. By default, the $(VCTargetsPath) macro references this directory. The *version* placeholder refers to the Visual Studio version: v160 for Visual Studio 2019, v150 for Visual Studio 2017.
 
-- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\VCTargets\\Platforms\\*platform*\\
+- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\Platforms\\*platform*\\
 
   Contains platform-specific target and property files that override targets and properties in its parent directory. This directory also contains a DLL that defines the tasks that are used by the targets in this directory. The *platform* placeholder represents the ARM, Win32, or x64 subdirectory.
 
-- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\VCTargets\\Platforms\\*platform*\\PlatformToolsets\\*toolset*\\
+- %VSINSTALLDIR%MSBuild\\Microsoft\\VC\\*version*\\Platforms\\*platform*\\PlatformToolsets\\*toolset*\\
 
   Contains the directories that enable the build to generate C++ applications by using the specified *toolset*. The *platform* placeholder represents the ARM, Win32, or x64 subdirectory. The *toolset* placeholder represents the toolset subdirectory.
 
diff --git a/docs/build/reference/std-specify-language-standard-version.md b/docs/build/reference/std-specify-language-standard-version.md
@@ -12,7 +12,7 @@ Enable supported C++ language features from the specified version of the C++ lan
 
 > **`/std:c++14`**\
 > **`/std:c++17`**\
-> **`/std:c++latest`**]
+> **`/std:c++latest`**
 
 ## Remarks
 
diff --git a/docs/code-quality/c26406.md b/docs/code-quality/c26406.md
@@ -1,17 +1,23 @@
 ---
 title: C26406
-ms.date: 07/21/2017
+ms.date: 08/18/2020
 ms.topic: "conceptual"
 f1_keywords: ["C26406"]
 helpviewer_keywords: ["C26406"]
 ms.assetid: 02fb8e23-1989-4e24-a5a5-e30f71d00325
 ---
 # C26406  DONT_ASSIGN_RAW_TO_OWNER
 
-Owners are initialized from allocations or from other owners. Assigning a value from a raw pointer to an owner pointer is not allowed. Raw pointers don’t guarantee ownership transfer; there is still may be an original owner which holds the resource and will attempt to release it. Note that assigning a value from owner to a raw pointer is fine; raw pointers are valid clients to access resources, but not to manage them.
+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).
+
+## Remarks
+
+Owners are initialized from allocations or from other owners. This warning occurs when you assign a value from a raw pointer to an owner pointer. Raw pointers don’t guarantee ownership transfer; the original owner may still hold the resource and attempt to release it. It's okay to assign a value from an owner to a raw pointer. Raw pointers are valid clients to access resources, but not to manage them.
 
 ## Example 1:  Using address of object
 
+This sample attempts to assign ownership of the address of `defaultSocket` to owner pointer `socket`:
+
 ```cpp
 gsl::owner<Socket*> socket = defaultSocket ? &defaultSocket : new Socket(); // C26406
 ```
diff --git a/docs/code-quality/c26407.md b/docs/code-quality/c26407.md
@@ -1,24 +1,24 @@
 ---
 title: C26407
-ms.date: 07/21/2017
+ms.date: 08/18/2020
 ms.topic: "conceptual"
 f1_keywords: ["C26407"]
 helpviewer_keywords: ["C26407"]
 ms.assetid: 5539907a-bfa0-40db-82a6-b860c97209e1
 ---
 # C26407 DONT_HEAP_ALLOCATE_UNNECESSARILY
 
-To avoid unnecessary use of pointers we try to detect common patterns of local allocations, for example when the result of a call to operator new is stored in a local variable and later explicitly deleted. This supports the rule R.5: *Prefer scoped objects, don't heap-allocate unnecessarily*. The suggested fix is to use an RAII type instead of a raw pointer and allow it to deal with resources. If an allocation is a single object, then it may be obviously unnecessary and 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 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.
 
 ## Remarks
 
-- To reduce the number of warnings, this pattern is detected for owner pointers only. So, it is necessary to mark owners properly first. We can easily extend this to cover raw pointers if we receive feedback from customers in support of such scenario.
+- To reduce the number of warnings, code analysis only detects this pattern for owner pointers. So, it's necessary to mark owners properly first. We can easily extend this to cover raw pointers if we receive [feedback](https://developercommunity.visualstudio.com/spaces/62/index.html) from customers in support of such scenarios.
 
-- The scoped object term may be a bit misleading, but the general idea is that we suggest using either a local variable whose lifetime is automatically managed, or a smart object which efficiently manages dynamic resources. Smart objects can of course do heap allocations, but it is not explicit in the code.
+- The *scoped object* term may be a bit misleading. In general, we suggest you use either a local variable whose lifetime is automatically managed, or a smart object that efficiently manages dynamic resources. Smart objects can of course do heap allocations, but it's not explicit in the code.
 
-- If the warning fires on array allocation (which is usually needed for dynamic buffers), the fix can be to use standard containers, or `std::unique_pointer<T[]>`.
+- If the warning fires on array allocation, (which is usually needed for dynamic buffers), you can fix it by using standard containers, or `std::unique_pointer<T[]>`.
 
-- The pattern is detected only for local variables, so we don’t warn on cases where an allocation is assigned to, say, a global variable and then deleted in the same function.
+- The pattern is detected only for local variables. We don’t warn in cases where an allocation is assigned to, say, a global variable and then deleted in the same function.
 
 ## Example 1: Unnecessary object allocation on heap
 
diff --git a/docs/code-quality/c26427.md b/docs/code-quality/c26427.md
@@ -11,7 +11,7 @@ ms.assetid: 8fb95a44-8704-45b1-bc55-eccd59b1db2f
 "Global initializer accesses extern object."
 
 **C++ Core Guidelines**:
-I.22: Avoid complex initialization of global objects
+[I.22](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i22-avoid-complex-initialization-of-global-objects): 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`**.
 
diff --git a/docs/code-quality/c26498.md b/docs/code-quality/c26498.md
@@ -1,10 +1,35 @@
 ---
 title: C26498
-ms.date: 03/22/2018
+ms.date: 08/18/2020
 ms.topic: reference
 f1_keywords: ["C26498"]
 helpviewer_keywords: ["C26498"]
 ---
 # C26498 USE_CONSTEXPR_FOR_FUNCTIONCALL
 
-This function call %function% can use `constexpr` if compile-time evaluation is desired. See [C++ Core Guidelines con.5](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rconst-constexpr).
+This rule helps to enforce Con.5 from the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#con5-use-constexpr-for-values-that-can-be-computed-at-compile-time): use constexpr for values that can be computed at compile time. 
+
+## Remarks
+
+The warning is triggered by assigning the result of a **`constexpr`** function to any non-**`constexpr`** variable whose value doesn't change after the initial assignment.
+
+## Example
+
+This sample code shows where C26498 may appear, and how to avoid it:
+
+```cpp
+constexpr int getMyValue()
+{
+    return 1;
+}
+
+void foo()
+{
+    constexpr int val0 = getMyValue(); // no C26498
+    const int val1 = getMyValue();     // C26498, C26814
+    int val2 = getMyValue();           // C26498, value is never modified
+    int val3 = getMyValue();           // no C26498, val3 is assigned to below.
+    val3 = val3 * val2;
+}
+```
+
