Merge branch 'main' of https://github.com/MicrosoftDocs/cpp-docs-pr into conformance

Author: TylerMSFT

docs/overview/how-to-report-a-problem-with-the-visual-cpp-toolset.md

@@ -408,6 +408,6 @@ To maintain your privacy and keep your sensitive information out of public view,
 
 ## How to report a C++ documentation issue
 
-We use GitHub issues to track problems reported in our documentation. You can now create GitHub issues directly from a content page, which enables you interact in a richer way with writers and product teams. If you see an issue with a document, a bad code sample, a confusing explanation, a critical omission, or even just a typo, you can easily let us know. Scroll to the bottom of the page and select **Sign in to give documentation feedback**. You need to create a GitHub account if you don't have one already. When you have a GitHub account, you can see all of our documentation issues and their status. You also get notifications when changes are made for the issue you reported. For more information, see our [Feedback System blog entry](/teamblog/a-new-feedback-system-is-coming-to-docs).
+If you see an issue with a document, a bad code sample, a confusing explanation, a critical omission, or even just a typo, you can easily let us know by using the feedback buttons on the page. Since 2024, we no longer use GitHub issues to track problems reported. For more information, see [Announcing a new way to give feedback on Microsoft Learn](https://techcommunity.microsoft.com/blog/microsoftlearnblog/announcing-a-new-way-to-give-feedback-on-microsoft-learn/4027635).
 
-You create a documentation issue on GitHub when you use the documentation feedback button. The issue is automatically filled in with some information about the page you created the issue on. That's how we know where the problem is located, so don't edit this information. Just append the details about what's wrong, and if you like, a suggested fix. [Our C++ docs are open source](https://github.com/MicrosoftDocs/cpp-docs/), so if you'd like to submit a fix yourself, you can. For more information about how you can contribute to our documentation, see our [Contributing guide](https://github.com/MicrosoftDocs/cpp-docs/blob/main/CONTRIBUTING.md) on GitHub.
+[Our C++ docs are open source](https://github.com/MicrosoftDocs/cpp-docs/), so if you'd like to submit a fix yourself, you can. For more information about how you can contribute to our documentation, see our [Contributing guide](https://github.com/MicrosoftDocs/cpp-docs/blob/main/CONTRIBUTING.md) on GitHub.

docs/parallel/concrt/cancellation-in-the-ppl.md

@@ -215,7 +215,7 @@ This example produces the following output.
 Caught 50
 ```
 
-The following example uses a Boolean flag to coordinate cancellation in a `parallel_for` loop. Every task runs because this example does not use the `cancel` method or exception handling to cancel the overall set of tasks. Therefore, this technique can have more computational overhead than a cancelation mechanism.
+The following example uses a Boolean flag to coordinate cancellation in a `parallel_for` loop. Every task runs because this example does not use the `cancel` method or exception handling to cancel the overall set of tasks. Therefore, this technique can have more computational overhead than a cancellation mechanism.
 
 [!code-cpp[concrt-task-tree#8](../../parallel/concrt/codesnippet/cpp/cancellation-in-the-ppl_14.cpp)]
 

docs/parallel/concrt/codesnippet/CPP/cancellation-in-the-ppl_12.cpp

@@ -1,4 +1,4 @@
-   // To enable cancelation, call parallel_for in a task group.
+   // To enable cancellation, call parallel_for in a task group.
    structured_task_group tg;
 
    task_group_status status = tg.run_and_wait([&] {

docs/parallel/concrt/codesnippet/CPP/cancellation-in-the-ppl_14.cpp

@@ -1,4 +1,4 @@
-   // Create a Boolean flag to coordinate cancelation.
+   // Create a Boolean flag to coordinate cancellation.
    bool canceled = false;
 
    parallel_for(0, 100, [&](int i) {

docs/parallel/concrt/codesnippet/CPP/cancellation-in-the-ppl_6.cpp

@@ -23,7 +23,7 @@
          for (int i = 0; i < 1000; ++i)
          {
             // To reduce overhead, occasionally check for 
-            // cancelation.
+            // cancellation.
             if ((i%100) == 0)
             {
                if (tg2.is_canceling())

docs/parallel/concrt/task-parallelism-concurrency-runtime.md

@@ -257,7 +257,7 @@ The runtime also provides an exception-handling model that enables you to throw
 
 Although we recommend that you use `task_group` or `parallel_invoke` instead of the `structured_task_group` class, there are cases where you want to use `structured_task_group`, for example, when you write a parallel algorithm that performs a variable number of tasks or requires support for cancellation. This section explains the differences between the `task_group` and `structured_task_group` classes.
 
-The `task_group` class is thread-safe. Therefore you can add tasks to a `task_group` object from multiple threads and wait on or cancel a `task_group` object from multiple threads. The construction and destruction of a `structured_task_group` object must occur in the same lexical scope. In addition, all operations on a `structured_task_group` object must occur on the same thread. The exception to this rule is the [concurrency::structured_task_group::cancel](reference/structured-task-group-class.md#cancel) and [concurrency::structured_task_group::is_canceling](reference/structured-task-group-class.md#is_canceling) methods. A child task can call these methods to cancel the parent task group or check for cancelation at any time.
+The `task_group` class is thread-safe. Therefore you can add tasks to a `task_group` object from multiple threads and wait on or cancel a `task_group` object from multiple threads. The construction and destruction of a `structured_task_group` object must occur in the same lexical scope. In addition, all operations on a `structured_task_group` object must occur on the same thread. The exception to this rule is the [concurrency::structured_task_group::cancel](reference/structured-task-group-class.md#cancel) and [concurrency::structured_task_group::is_canceling](reference/structured-task-group-class.md#is_canceling) methods. A child task can call these methods to cancel the parent task group or check for cancellation at any time.
 
 You can run additional tasks on a `task_group` object after you call the [concurrency::task_group::wait](reference/task-group-class.md#wait) or [concurrency::task_group::run_and_wait](reference/task-group-class.md#run_and_wait) method. Conversely, if you run additional tasks on a `structured_task_group` object after you call the [concurrency::structured_task_group::wait](reference/structured-task-group-class.md#wait) or [concurrency::structured_task_group::run_and_wait](reference/structured-task-group-class.md#run_and_wait) methods, then the behavior is undefined.
 

docs/porting/binary-compat-2015-2017.md

@@ -1,31 +1,31 @@
 ---
-title: "C++ binary compatibility 2015-2022"
-description: "Describes how binary compatibility works between compiled C++ files in Visual Studio 2015, 2017, 2019, and 2022. One Microsoft Visual C++ Redistributable package works for all three versions."
-ms.date: 03/07/2024
+title: "C++ binary compatibility 2015-2026"
+description: "Describes how binary compatibility works between compiled C++ files in Visual Studio 2015, 2017, 2019, 2022, and 2026. One Microsoft Visual C++ Redistributable package works for all these versions."
+ms.date: 10/29/2025
 helpviewer_keywords: ["binary compatibility, Visual C++"]
 ---
 # C++ binary compatibility between Visual Studio versions
 
-The Microsoft C++ (MSVC) compiler toolsets in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these toolsets. The ABIs, object formats, and runtime libraries are incompatible.
+The Microsoft C++ (MSVC) Build Tools in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these build tools. The ABIs, object formats, and runtime libraries are incompatible.
 
-We've changed this behavior in Visual Studio 2015 and later versions. The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the C++ toolset major number, which starts with 14 for all versions since Visual Studio 2015. (The toolset version is v140 for Visual Studio 2015, v141 for 2017, v142 for 2019, and v143 for 2022). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017, 2019, or 2022. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
+We've changed this behavior in Visual Studio 2015 and later versions. The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the MSVC Build Tools major number, which starts with 14 for all versions since Visual Studio 2015. (The build tools version is v140 for Visual Studio 2015, v141 for 2017, v142 for 2019, and v143 for 2022). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017, 2019, 2022, or 2026. There's no need to recompile with a matching version. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
 
 ## <a name="restrictions"></a> Restrictions on binary compatibility
 
-There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates:
+There are three important restrictions on binary compatibility between the v140, v141, v142, v143, and v145 build tools and minor numbered version updates:
 
-- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by a toolset that is the same version (or earlier) as itself. This applies to apps, import libraries, static libraries, and other files as described in [LINK input files](../build/reference/link-input-files.md). In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means:
-    - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2022 version 17.8 (v143), but the linking must be done using a version 17.8 or later toolset.
-    - Apps and libraries built using VS 2015, 2017, 2019, or 2022 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries you pass to the linker. For example, given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.9, and VS 2019 version 16.11, you can link them using any toolset version that is 16.11 or later.
-    - If a DLL is built with a newer toolset, the import library can sometimes be used with older toolsets if all of the exports follow the C language calling convention (`extern "C"`). However, the only officially supported case is consuming a newer windows SDK with an older toolset.
-- The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.
-- Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md).
+- Binaries created with different versions of the v140, v141, v142, v143, and v145 build tools can be combined. The key rule is that the linker should only work with inputs built by build tools that are the same version (or earlier) as itself. This applies to apps, import libraries, static libraries, and other files as described in [LINK input files](../build/reference/link-input-files.md). In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the build tools can be linked using an earlier version of the build tools--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means:
+    - An app compiled with the 2017 build tools (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2022 version 17.8 (v143), but the linking must be done using a version 17.8 or later build tools.
+    - Apps and libraries built using VS 2015, 2017, 2019, 2022, and 2026 can be linked together, but the linking must be done using a version of the build tools that is as recent as, or more recent than, the most recent build tools used to build any of the binaries you pass to the linker. For example, given three binaries built with build tools from VS 2015 version 14.3, VS 2017 version 15.9, and VS 2019 version 16.11, you can link them using any build tools version that is 16.11 or later.
+    - If a DLL is built with newer build tools, the import library can sometimes be used with older build tools if all of the exports follow the C language calling convention (`extern "C"`). However, the only officially supported case is consuming a newer windows SDK with older build tools.
+- The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the build tools, the Redistributable version must be at least as new as the latest build tools used by any app component.
+- Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same build tools for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 build tools can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 build tools. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md).
 
 ## Upgrade the Microsoft Visual C++ Redistributable from Visual Studio 2015 and later
 
-We've kept the Microsoft Visual C++ Redistributable major version number the same for Visual Studio 2015, 2017, 2019, and 2022. That means only one instance of the Redistributable can be installed at a time. A newer version overwrites any older version that's already installed. For example, one app may install the Redistributable from Visual Studio 2015. Then, another app installs the Redistributable from Visual Studio 2022. The 2022 version overwrites the older version, but because they're binary-compatible, the earlier app still works fine. We make sure the latest version of the Redistributable has all the newest features, security updates, and bug fixes. That's why we always recommend you upgrade to the latest available version.
+We've kept the Microsoft Visual C++ Redistributable major version number the same for Visual Studio 2015, 2017, 2019, 2022, and 2026. That means only one instance of the Redistributable can be installed at a time. A newer version overwrites any older version that's already installed. For example, one app may install the Redistributable from Visual Studio 2015. Then, another app installs the Redistributable from Visual Studio 2026. The 2026 version overwrites the older version, but because they're binary-compatible, the earlier app still works fine. We make sure the latest version of the Redistributable has all the newest features, security updates, and bug fixes. That's why we always recommend you upgrade to the latest available version.
 
-Similarly, you can't install an older Redistributable when a newer version is already installed. The installer reports an error if you try. You'll see an error like this if you install the 2017 or 2019 Redistributable on a machine that already has the 2022 version:
+Similarly, you can't install an older Redistributable when a newer version is already installed. The installer reports an error if you try. For example, you'll see an error like this if you install the 2022 Redistributable on a machine that already has the 2026 version:
 
 ```Output
 0x80070666 - Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.

docs/porting/build-system-changes.md

@@ -7,7 +7,7 @@ ms.assetid: e564d95f-a6cc-4d97-b57e-1a71daf66f4a
 ---
 # VCBuild vs. MSBuild: Build system changes in Visual Studio 2010
 
-The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade to the current IDE and compiler toolset. For more information, including how to obtain Visual Studio 2010, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).
+The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade to the current IDE and build tools. For more information, including how to obtain Visual Studio 2010, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).
 
 The following sections summarize the changes from VCBuild to MSBuild. If your VCBuild project has custom build rules or macros that aren't recognized by MSBuild, see [Visual Studio Projects - C++](../build/creating-and-managing-visual-cpp-projects.md) to learn how to translate those instructions to the MSBuild system. The initial conversion from VCBuild to MSBuild is just an intermediate step. It isn't necessary to get the project file completely correct or to get the program to compile without errors. You are only using Visual Studio 2010 to convert the project to MSBuild format so that you get the project working in the latest version of Visual Studio.