Repo sync for protected CLA branch

docs/build/cmake-presets-vs.md

@@ -25,18 +25,20 @@ Visual Studio supports version 2 or later for the *`CMakePresets.json`* and *`CM
 
 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.
 
-## <a name="enable-cmakepresets-json-integration"> Enable  *`CMakePresets.json`* integration in Visual Studio 2019
+## <a name="enable-cmakepresets-json-integration"> Enable  *`CMakePresets.json`* integration in Visual Studio
 
-*`CMakePresets.json`* integration isn't enabled by default in Visual Studio 2019. You can enable it for all CMake projects in **Tools** > **Options** > **CMake** > **General**:
+*`CMakePresets.json`* integration isn't enabled by default in Visual Studio. You can enable it in **Tools** > **Options** > **CMake** > **General**:
 
-![Screenshot showing the checkbox to enable CMakePresets.json on the CMake General page of the Tools Options dialog.](./media/enable-cmakepresets.png)
+![Screenshot showing the checkbox to enable CMakePresets.json on the CMake General page of the Tools Options dialog in Visual Studio 2022 version 17.1.](./media/enable-cmakepresets-new.png)
 
 > [!Important]
 > Close and reopen the folder in Visual Studio to activate the integration.
 
-If you don't want to enable *`CMakePresets.json`* integration for all CMake projects, you can enable *`CMakePresets.json`* integration for a single CMake project by adding a *`CMakePresets.json`* file to the root of the open folder. Close and reopen the folder in Visual Studio to activate the integration.
+In Visual Studio 2022 version 17.0 and Visual Studio 2019, **Tools** > **Options** > **CMake** > **General** has a single option to enable *`CMakePresets.json`* integration. 
 
-The following table indicates when *`CMakePresets.json`* is used instead of *`CMakeSettings.json`* to drive CMake configuration and build. If no configuration file is present, default Configure Presets are used.
+![Screenshot showing the checkbox to enable CMakePresets.json on the CMake General page of the Tools Options dialog in Visual Studio 2019.](./media/enable-cmakepresets.png)
+
+The following table indicates when *`CMakePresets.json`* is used instead of *`CMakeSettings.json`* to drive CMake configuration and build in Visual Studio 2022 version 17.0 and Visual Studio 2019. If no configuration file is present, default Configure Presets are used.
 
 In the table, "**Tools** > **Options** enabled" means **Use CMakePresets.json to drive CMake configure, build, and test** is selected in **Tools** > **Options** > **CMake** > **General**.
 

docs/build/walkthrough-build-debug-wsl2.md

@@ -55,7 +55,7 @@ Visual Studio defines a CMake project as a folder with a `CMakeLists.txt` file a
 
 4. In the **Search for templates** textbox, type "cmake".  Choose the **CMake Project** type and select **Next**. Give the project a name and location, and then select **Create**.
 
-5. Enable Visual Studio’s CMake Presets integration. Select **Tools** > **Options** > **CMake** > **General**. Select **Prefer using CMake Presets for configure, build, and test**, then select **OK**. Instead, you could have added a `CMakePresets.json` file to the root of the project. For more information, see [Enable CMake Presets integration](cmake-presets-vs.md#-enable--cmakepresetsjson-integration-in-visual-studio-2019).
+5. Enable Visual Studio’s CMake Presets integration. Select **Tools** > **Options** > **CMake** > **General**. Select **Prefer using CMake Presets for configure, build, and test**, then select **OK**. Instead, you could have added a `CMakePresets.json` file to the root of the project. For more information, see [Enable CMake Presets integration](cmake-presets-vs.md#-enable--cmakepresetsjson-integration-in-visual-studio).
 
     ![Screenshot of CMake general options screen with Prefer using CMake Presets for configure, build, and test highlighted and selected](media/cmake-general-prefer-cmake-presets.png)
 
@@ -102,7 +102,7 @@ You've now built and debugged a C++ app with WSL 2 and Visual Studio 2022.
 
 ## Advanced WSL 2 and CMake projects considerations
 
-Visual Studio only provides native support for WSL 2 for CMake projects that use `CMakePresets.json` as the active configuration file. To migrate from `CMakeSettings.json` to `CMakePresets.json`, see [Enable CMake Presets integration in Visual Studio](cmake-presets-vs.md#-enable--cmakepresetsjson-integration-in-visual-studio-2019).
+Visual Studio only provides native support for WSL 2 for CMake projects that use `CMakePresets.json` as the active configuration file. To migrate from `CMakeSettings.json` to `CMakePresets.json`, see [Enable CMake Presets integration in Visual Studio](cmake-presets-vs.md#-enable--cmakepresetsjson-integration-in-visual-studio).
 
 If you're targeting a WSL 2 distribution and you don't want to use the WSL 2 toolset, then in the Visual Studio Remote Settings vendor map in `CMakePresets.json`, set **forceWSL1Toolset** to **true** . See [Visual Studio Remote Settings vendor map](cmake-presets-json-reference.md#visual-studio-remote-settings-vendor-map) for details.
 

docs/error-messages/compiler-warnings/compiler-warning-level-2-c4146.md

@@ -1,42 +1,43 @@
 ---
-description: "Learn more about: Compiler Warning (level 2) C4146"
-title: "Compiler Warning (level 2) C4146"
-ms.date: "11/04/2016"
+description: "Learn more about: Compiler warning (level 2) C4146"
+title: "Compiler warning (level 2) C4146"
+ms.date: 11/18/2021
 f1_keywords: ["C4146"]
 helpviewer_keywords: ["C4146"]
-ms.assetid: d6c31ab1-3120-40d5-8d80-32b5f7046e32
 ---
-# Compiler Warning (level 2) C4146
+# Compiler warning (level 2) C4146
 
-unary minus operator applied to unsigned type, result still unsigned
+> unary minus operator applied to unsigned type, result still unsigned
 
-Unsigned types can hold only non-negative values, so unary minus (negation) does not usually make sense when applied to an unsigned type. Both the operand and the result are non-negative.
+Unsigned types can hold only non-negative values, so unary minus (negation) usually doesn't make sense when applied to an unsigned type. Both the operand and the result are non-negative.
 
-Practically, this occurs when the programmer is trying to express the minimum integer value, which is -2147483648. This value cannot be written as -2147483648 because the expression is processed in two stages:
+## Remarks
 
-1. The number 2147483648 is evaluated. Because it is greater than the maximum integer value of 2147483647, the type of 2147483648 is not [int](../../c-language/integer-types.md), but **`unsigned int`**.
+When you express a negative integer literal, the **`-`** in front of the value is parsed as a [unary negation](../../cpp/unary-plus-and-negation-operators-plus-and.md) operator. The compiler applies the operator after it parses the numeric value. If the numeric value fits in the range of an unsigned integer type, but not the corresponding signed integer type, the compiler interprets the value as unsigned. An unsigned value is unchanged by the unary negation operator.
 
-1. Unary minus is applied to the value, with an unsigned result, which also happens to be 2147483648.
+This warning often occurs when you try to express the minimum **`int`** value, -2147483648, or the minimum **`long long`** value, -9223372036854775808. These values can't be written as -2147483648 or -9223372036854775808ll, respectively. That's because the compiler processes the expression in two stages: first, it parses the numeric value, then it applies the negation operator. For example, when the compiler parses -2147483648, it follows these steps:
 
-The unsigned type of the result can cause unexpected behavior. If the result is used in a comparison, then an unsigned comparison might be used, for example, when the other operand is an **`int`**. This explains why the example program below prints just one line.
+1. The number 2147483648 is evaluated. Because it's greater than the maximum **`int`** value of 2147483647, but still fits in an **`unsigned int`**, the type of 2147483648 is **`unsigned int`**.
 
-The expected second line, `1 is greater than the most negative int`, is not printed because `((unsigned int)1) > 2147483648` is false.
+1. Unary minus is applied to the unsigned value, with an unsigned result, which also happens to be 2147483648.
 
-You can avoid C4146 by using INT_MIN from limits.h, which has the type **`signed int`**.
+The unsigned type of the result can cause unexpected behavior. If the result is used in a comparison, then an unsigned comparison might be used, for example, when the other operand is an **`int`**.
+
+You can avoid C4146 by using `INT_MIN` or `LLONG_MIN` from *`<limits.h>`* or the C++ equivalent, *`<climits>`*. These values have signed types.
 
 ## Example
 
-The following sample generates C4146:
+The following sample demonstrates the unexpected behavior that can happen when the compiler generates warning C4146:
 
 ```cpp
 // C4146.cpp
 // compile with: /W2
-#include <stdio.h>
+#include <iostream>
 
 void check(int i)
 {
-    if (i > -2147483648)   // C4146
-        printf_s("%d is greater than the most negative int\n", i);
+    if (i > -9223372036854775808ll)   // C4146
+        std::cout << i << " is greater than the most negative long long int.\n";
 }
 
 int main()
@@ -45,3 +46,11 @@ int main()
     check(1);
 }
 ```
+
+In this example, the compiler considers -9223372036854775808ll unsigned even though the literal has an `ll` suffix and the negation operator is applied. To make the `<` comparison, the compiler silently promotes signed `i` to `unsigned long long int`. The expected second line, `1 is greater than the most negative long long int`, isn't printed because `((unsigned long long int)1) > 9223372036854775808ull` is false.
+
+To fix the example, include *`<climits>`* and change -9223372036854775808ll to `LLONG_MIN`.
+
+## See also
+
+[Unary negation operator (-)](../../cpp/unary-plus-and-negation-operators-plus-and.md)

docs/overview/what-s-new-for-visual-cpp-in-visual-studio.md

@@ -81,7 +81,7 @@ Select Standard Library (STL) improvements are highlighted here. For a comprehen
 
 ### C++ AMP deprecated
 
-- C++ AMP headers are now deprecated. Including `<amp.h>` in a C++ project generates build errors. To silence the errors, define `_SILENCE_AMP_DEPRECATION_WARNINGS`. For more information, see [our AMP Deprecation links](https://aka.ms/amp_deprecate).
+- C++ AMP headers are now deprecated. Including `<amp.h>` in a C++ project generates build errors. To silence the errors, define `_SILENCE_AMP_DEPRECATION_WARNINGS`. For more information, see [our AMP Deprecation links](/cpp/parallel/amp/cpp-amp-overview).
 
 ### IntelliSense improvements
 
@@ -127,4 +127,4 @@ We'd love to hear from you! You can [Report a Problem or Suggest a Feature](/vis
 
 ## Blogs
 
-Take advantage of the insights and recommendations available in the [Microsoft Developer Blogs](https://devblogs.microsoft.com/) site. They'll keep you up to date on all new releases. The blogs include deep dive posts on a broad range of features. You'll find the [C++ Team Blog](https://devblogs.microsoft.com/cppblog) and the [Visual Studio Blog](https://devblogs.microsoft.com/visualstudio) of particular interest.
+Take advantage of the insights and recommendations available in the [Microsoft Developer Blogs](https://devblogs.microsoft.com/) site. They'll keep you up to date on all new releases. The blogs include deep dive posts on a broad range of features. You'll find the [C++ Team Blog](https://devblogs.microsoft.com/cppblog) and the [Visual Studio Blog](https://devblogs.microsoft.com/visualstudio) of particular interest.