Repo sync for protected CLA branch

docs/build/cmake-presets-vs.md

@@ -1,7 +1,7 @@
 ---
 title: Configure and build with CMake Presets
 description: "Reference for using CMake Presets to configure and build CMake projects."
-ms.date: 04/07/2022
+ms.date: 09/13/2022
 ms.topic: reference
 ---
 
@@ -21,9 +21,9 @@ We recommend *`CMakePresets.json`* as an alternative to *`CMakeSettings.json`*.
 
 ## Supported CMake and  *`CMakePresets.json`* versions
 
-Visual Studio supports version 2 or later for the *`CMakePresets.json`* and *`CMakeUserPresets.json`* files. You can update your file version by incrementing the version field in the root object. For an example and more information, see [`CMakePresets.json` format](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html#format).
+The supported *`CMakePresets.json`* and *`CMakeUserPresets.json`* schema versions depend on your version of Visual Studio. Visual Studio 2019 version 16.10 and later support schema versions 2 and 3. Visual Studio 2022 version 17.4 preview 2 adds support for schema versions 4 and 5. You can update the version by changing the `"version"` field in the root object. For an example and more information, see [`CMakePresets.json` format](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html#format).
 
-CMake version 3.20 or later is required when you're invoking CMake with *`CMakePresets.json`* (version 2 or later) from the command line. However, Visual Studio reads and evaluates *`CMakePresets.json`* and *`CMakeUserPresets.json`* itself and doesn't invoke CMake directly with the `--preset` option. So, CMake version 3.20 or later isn't strictly required when you're building with *`CMakePresets.json`* inside Visual Studio. We recommend using CMake version 3.14 or later.
+CMake version 3.20 or later is required when you're invoking CMake with *`CMakePresets.json`* from the command line. However, Visual Studio reads and evaluates *`CMakePresets.json`* and *`CMakeUserPresets.json`* itself and doesn't invoke CMake directly with the `--preset` option. So, CMake version 3.20 or later isn't strictly required when you're building with *`CMakePresets.json`* inside Visual Studio. We recommend using at least CMake version 3.14 or later.
 
 ## <a name="enable-cmakepresets-json-integration"></a> Enable *`CMakePresets.json`* integration in Visual Studio
 

docs/c-runtime-library/reference/getch-getwch.md

@@ -8,7 +8,6 @@ api_type: ["DLLExport"]
 topic_type: ["apiref"]
 f1_keywords: ["getwch", "_getch", "_getwch"]
 helpviewer_keywords: ["characters, getting from console", "getch function", "_getwch function", "console, reading from", "_getch function", "getwch function"]
-ms.assetid: cc116be7-cff2-4274-970f-5e7b18ccc05c
 ---
 # `_getch`, `_getwch`
 
@@ -30,9 +29,9 @@ Returns the character read. There's no error return.
 
 ## Remarks
 
-The **`_getch`** and **`_getwch`** functions read a single character from the console without echoing the character. None of these functions can be used to read CTRL+C. When reading a function key or an arrow key, each function must be called twice; the first call returns 0 or 0xE0, and the second call returns the actual key code.
+The **`_getch`** and **`_getwch`** functions read a single character from the console without echoing the character. None of these functions can be used to read CTRL+C. To read a function key or arrow key, each function must be called twice. The first call returns `0` or `0xE0`. The second call returns the [key scan code](/previous-versions/visualstudio/visual-studio-6.0/aa299374(v=vs.60)).
 
-These functions lock the calling thread and are therefore thread-safe. For non-locking versions, see [`_getch_nolock`, `_getwch_nolock`](getch-nolock-getwch-nolock.md).
+These functions lock the calling thread and so are thread-safe. For non-locking versions, see [`_getch_nolock`, `_getwch_nolock`](getch-nolock-getwch-nolock.md).
 
 By default, this function's global state is scoped to the application. To change this, see [Global state in the CRT](../global-state.md).
 
@@ -89,8 +88,8 @@ Type 'Y' when finished typing keys: Y
 
 ## See also
 
-[Console and Port I/O](../../c-runtime-library/console-and-port-i-o.md)<br/>
-[`_getche`, `_getwche`](getche-getwche.md)<br/>
-[`_cgets`, `_cgetws`](../../c-runtime-library/cgets-cgetws.md)<br/>
-[`getc`, `getwc`](getc-getwc.md)<br/>
-[`_ungetch`, `_ungetwch`, `_ungetch_nolock`, `_ungetwch_nolock`](ungetch-ungetwch-ungetch-nolock-ungetwch-nolock.md)<br/>
+[Console and Port I/O](../../c-runtime-library/console-and-port-i-o.md)\
+[`_getche`, `_getwche`](getche-getwche.md)\
+[`_cgets`, `_cgetws`](../../c-runtime-library/cgets-cgetws.md)\
+[`getc`, `getwc`](getc-getwc.md)\
+[`_ungetch`, `_ungetwch`, `_ungetch_nolock`, `_ungetwch_nolock`](ungetch-ungetwch-ungetch-nolock-ungetwch-nolock.md)

docs/code-quality/c26495.md

@@ -1,21 +1,25 @@
 ---
 title: C26495
-ms.date: 05/23/2022
+ms.date: 08/18/2022
 ms.topic: reference
-f1_keywords: ["C26495"]
+f1_keywords: ["C26495", "MEMBER_UNINIT", "__WARNING_MEMBER_UNINIT"]
 helpviewer_keywords: ["C26495"]
 description: CppCoreCheck rule that enforces C++ Core Guidelines Type.6
 ---
-# C26495 MEMBER_UNINIT
+# Warning C26495
 
-> Variable '*identifier*' is uninitialized. Always initialize a member variable (type.6).
+> Variable '\**parameter-name*' is uninitialized. Always initialize a member variable (type.6).
 
 ## Remarks
 
 A member variable isn't initialized by a constructor or by an initializer. Make sure all variables are initialized by the end of construction. For more information, see C++ Core Guidelines [Type.6](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#SS-type) and [C.48](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers).
 
+Code analysis name: MEMBER_UNINIT
+
 ## Example
 
+The following sample generates warning C26495 because the member variable `value` isn't initialized when a `MyStruct` object is created.
+
 ```cpp
 struct MyStruct
 {
@@ -24,12 +28,12 @@ struct MyStruct
 };
 ```
 
-To fix the warning, add in-class initialization to all of the member variables:
+To resolve the issue, you can add in-class initialization to all of the member variables.
 
 ```cpp
 struct MyStruct
 {
-    int value{};
+    int value{};  // empty brace initializer sets value to 0
     MyStruct() {} // no warning, MyStruct::value is set via default member initialization
 };
 ```

docs/code-quality/c6101.md

@@ -1,14 +1,39 @@
 ---
 description: "Learn more about: C6101"
 title: C6101
-ms.date: 11/04/2016
+ms.date: 08/17/2022
 ms.topic: reference
-f1_keywords: ["C6101"]
+f1_keywords: ["C6101", "RETURN_UNINIT_VAR", "__WARNING_RETURN_UNINIT_VAR"]
 helpviewer_keywords: ["C6101"]
 ms.assetid: 8546367c-5de5-479a-a231-c15c0aa89ef1
 ---
-# C6101
+# Warning C6101
 
-> warning C6101: Returning uninitialized memory
+> Returning uninitialized memory '\**parameter-name*'. A successful path through the function does not set the named \_Out\_ parameter.
 
-A successful path through the function does not set the named `_Out_` parameter. This message is generated based on SAL annotations that indicate that the function in question always succeeds. A function that doesn't return a success/failure indication should set all of its `_Out_` parameters because the analyzer assumes that the `_Out_` parameter is uninitialized data before the function is called, and that the function will set the parameter so that it's no longer uninitialized. If the function does indicate success/failure, then the `_Out_` parameter doesn't have to be set in the case of failure, and you can detect and avoid the uninitialized location. In either case, the objective is to avoid the reading of an uninitialized location. If the function sometimes doesn't touch an `_Out_` parameter that's subsequently used, then the parameter should be initialized before the function call and be marked with the `_Inout_` annotation, or the more explicit `_Pre_null_` or `_Pre_satisfies_()` when appropriate. "Partial success" can be handled with the `_When_` annotation. For more information, see [Using SAL Annotations to Reduce C/C++ Code Defects](../code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects.md).
+## Remarks
+
+This message is generated based on SAL annotations that indicate that the function in question always succeeds. A function that doesn't return a success/failure indication should set all of its `_Out_` parameters because the analyzer assumes that the `_Out_` parameter is uninitialized data before the function is called, and that the function will set the parameter so that it's no longer uninitialized. If, however, the function does indicate success/failure and failure occurs, then the `_Out_` parameter doesn't have to be set. You can then detect and avoid the uninitialized location. In either case, the objective is to avoid the reading of an uninitialized location. If the function sometimes doesn't touch an `_Out_` parameter that's later used, then the parameter should be initialized before the function call and be marked with the `_Inout_` annotation, or the more explicit `_Pre_null_` or `_Pre_satisfies_()` when appropriate. "Partial success" can be handled with the `_When_` annotation. For more information, see [Using SAL Annotations to Reduce C/C++ Code Defects](../code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects.md).
+
+Code analysis name: RETURN_UNINIT_VAR
+
+## Example
+
+The following code generates this warning. This issue stems from the pointer p1 not being set despite having been annotated with `_Out_`.
+
+```cpp
+void example_func(_Out_ int *p1)
+{
+    return;
+}
+```
+
+To resolve the issue, you can set the value of the parameter. Or, if the value is always initialized before the function is called, change the SAL annotation to `_Inout_`. By setting the value of the parameter, the following code avoids the warning:
+
+```cpp
+void example_func(_Out_ int *p1)
+{
+    *p1 = 1;
+    return;
+}
+```

docs/get-started/includes/git-source-control.md

@@ -20,7 +20,7 @@ To associate your code with Git, you start by creating a new Git repository wher
 
 1. In the **Create a Git repository** dialog box, sign in to GitHub.
 
-    :::image type="content" source="../media/vs-2022/git-create-repo.png" alt-text="Screenshot of the Create a Git Repository dialog window where you can sign in to GitHub.":::
+    :::image type="content" source="../media/vs-2022/git-create-repo.png" alt-text="Screenshot of the Create a Git Repository dialog window where you create a new GitHub repository.":::
 
     The repository name auto-populates based on your folder location. By default, your new repository is private, which means you're the only one who can access it.
 
@@ -29,9 +29,9 @@ To associate your code with Git, you start by creating a new Git repository wher
 
 1. Select **Create and Push**.
 
-    After you create your repository, you see status details in the status bar.
+    After you create your repository, status details appear in the status bar.
 
-    :::image type="content" source="../media/vs-2022/git-new-private-repo-status-details.png" alt-text="Screenshot of the repo status bar that's below the Solution Explorer pane in Visual Studio.":::
+    :::image type="content" source="../media/vs-2022/git-new-private-repo-status-details.png" alt-text="Screenshot of the repo status bar located below the Visual Studio Solution Explorer pane, showing the branch name and number of outstanding changes.":::
 
     The first icon with the arrows shows how many outgoing/incoming commits are in your current branch. You can use this icon to pull any incoming commits or push any outgoing commits. You can also choose to view these commits first. To do so, select the icon, and then select **View Outgoing/Incoming**.