Merge pull request #6106 from MicrosoftDocs/FromPublicMasterBranch

Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main)

Author: v-alje

docs/assembler/masm/option-language-masm.md

@@ -1,6 +1,6 @@
 ---
-description: Learn more about the alternatives for the OPTION LANGUAGE directive
 title: "OPTION LANGUAGE"
+description: "Learn more about the alternatives for the OPTION LANGUAGE directive"
 ms.date: 09/21/2021
 f1_keywords: ["language"]
 helpviewer_keywords: ["OPTION LANGUAGE directive"]
@@ -20,11 +20,11 @@ Available languages include:
 :::row:::
    :::column span="":::
       **`C`**\
-      **`SYSCALL`**\
+      **`SYSCALL`**
    :::column-end:::
    :::column span="":::
       **`STDCALL`**\
-      **`PASCAL`**\
+      **`PASCAL`**
    :::column-end:::
    :::column span="":::
       **`FORTRAN`**\

docs/build-insights/index.yml

@@ -17,7 +17,7 @@ landingContent:
 # Cards and links should be based on top customer tasks or top subjects
 # Start card title with a verb
   # Card (optional)
-  - title: Learn how your build performs 
+  - title: Learn how your build performs
     linkLists:
       - linkListType: overview
         links:

docs/build/arm64-exception-handling.md

@@ -1,6 +1,6 @@
 ---
 title: "ARM64 exception handling"
-description: Describes the exception handling conventions and data used by windows on ARM64.
+description: "Describes the exception handling conventions and data used by windows on ARM64."
 ms.date: 01/13/2023
 ---
 # ARM64 exception handling
@@ -287,7 +287,7 @@ The unwind codes are encoded according to the table below. All unwind codes are
 |--|--|
 | `alloc_s` | 000xxxxx: allocate small stack with size \< 512 (2^5 * 16). |
 | `save_r19r20_x` | 001zzzzz: save `<x19,x20>` pair at `[sp-#Z*8]!`, pre-indexed offset >= -248 |
-| `save_fplr` | 01zzzzzz: save `<x29,lr>` pair at `[sp+#Z*8]`,  offset \<= 504. |
+| `save_fplr` | 01zzzzzz: save `<x29,lr>` pair at `[sp+#Z*8]`, offset \<= 504. |
 | `save_fplr_x` | 10zzzzzz: save `<x29,lr>` pair at `[sp-(#Z+1)*8]!`, pre-indexed offset >= -512 |
 | `alloc_m` | 11000xxx'xxxxxxxx: allocate large stack with size \< 32K (2^11 * 16). |
 | `save_regp` | 110010xx'xxzzzzzz: save `x(19+#X)` pair at `[sp+#Z*8]`, offset \<= 504 |

docs/build/cmake-predefined-configuration-reference.md

@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: CMake predefined build configurations"
 title: "CMake predefined configuration reference"
+description: "Learn more about: CMake predefined build configurations"
 ms.description: "Visual Studio provides several predefined build configurations for CMake projects on Linux, Windows, ARM, and IoT."
 ms.date: 08/03/2021
 helpviewer_keywords: ["CMake redefined configurations"]
@@ -30,7 +30,7 @@ In a CMake project, build configurations are stored in a *`CMakeSettings.json`*
 
 When you choose a configuration, it's added to the *`CMakeSettings.json`* file in the project's root folder. You can then use it to build your project. For information about the configuration properties, see [CMakeSettings reference](cmakesettings-reference.md).
 
-## Linux predefined build configurations:
+## Linux predefined build configurations
 
 ```json
 {

docs/build/cmake-projects-in-visual-studio.md

@@ -3,7 +3,7 @@ title: "CMake projects in Visual Studio"
 description: "Learn how to create and build C++ projects using CMake in Visual Studio."
 ms.date: 03/18/2025
 ms.topic: concept-article
-f1_keywords: ["VS.ToolsOptionsPages.CMake.General", "VS.ToolsOptionsPages.CMake.LanguageServices"] 
+f1_keywords: ["VS.ToolsOptionsPages.CMake.General", "VS.ToolsOptionsPages.CMake.LanguageServices"]
 ms.custom: sfi-image-nochange
 ---
 

docs/build/launch-vs-schema-reference-cpp.md

@@ -17,7 +17,7 @@ To create the file, right-click on an executable file in **Solution Explorer** a
 | `args` | array | Specifies the command-line arguments passed to the launched program. |
 | `buildConfigurations` | array | A key-value pair that specifies the name of the build mode to apply the configurations. For example, `Debug` or `Release` and the configurations to use according to the selected build mode. |
 | `currentDir` | string | Specifies the full directory path to the Build Target. The directory is detected automatically unless this parameter is set. |
-| `cwd` | string | Full path to the directory on the remote system where the program will run. Defaults to `"${debugInfo.defaultWorkingDirectory}"` |
+| `cwd` | string | Full path to the directory on the remote system where the program will run. Defaults to `"${debugInfo.defaultWorkingDirectory}"`. |
 | `debugType` | string | Specifies the debugging mode according to the type of code (native, managed, or mixed). The mode is automatically detected unless this parameter is set. Allowed values: `"native"`, `"managed"`, `"mixed"`. |
 | `env` | array | Specifies a key-value list of custom environment variables. For example: `env:{"myEnv":"myVal"}`. |
 | `inheritEnvironments` | array | Specifies a set of environment variables inherited from multiple sources. You can define some variables in files like *`CMakeSettings.json`* or *`CppProperties.json`* and make them available to debug context.  **Visual Studio 16.4:** Specify environment variables on a per-target basis using the `env.VARIABLE_NAME` syntax. To unset a variable, set it to `"null"`. |
@@ -27,9 +27,9 @@ To create the file, right-click on an executable file in **Solution Explorer** a
 | `program` | string | The debug command to execute. Defaults to `"${debugInfo.fullTargetPath}"`. |
 | `project` | string | Specifies the relative path to the project file. Normally, you don't need to change this value when debugging a CMake project. |
 | `projectTarget` | string | Specifies the optional target invoked when building `project`. The target must match the name in the **Startup Item** dropdown. |
-| `stopOnEntry` | boolean | Specifies whether to break a soon as the process is launched and the debugger attaches. The default value for this parameter is **`false`**. |
+| `stopOnEntry` | boolean | Specifies whether to break as soon as the process is launched and the debugger attaches. The default value for this parameter is **`false`**. |
 | `remoteMachine` | string | Specifies the name of the remote machine where the program is launched. |
-| `type` | string | Specifies whether the project is a `dll` or `exe` Defaults to .exe |
+| `type` | string | Specifies whether the project is a `dll` or `exe`. Defaults to `"exe"`. |
 
 ## C++ Linux properties
 
@@ -64,7 +64,7 @@ The following macros provide information about the debugging environment. They'r
 
 | Macro | Description | Example |
 |--|--|--|
-| `addressSanitizerRuntimeFlags` | Runtime flags used to customize behavior of the address sanitizer. Used to set the environment variable `"ASAN_OPTIONS"`. | `"env": {"ASAN_OPTIONS": "${addressSanitizerRuntimeFlags}:anotherFlag=true"`} |
+| `addressSanitizerRuntimeFlags` | Runtime flags used to customize behavior of the address sanitizer. Used to set the environment variable `"ASAN_OPTIONS"`. | `"env": {"ASAN_OPTIONS": "${addressSanitizerRuntimeFlags}:anotherFlag=true"}` |
 | `defaultWorkingDirectory` | Set to the directory part of `"fullTargetPath"`. If the CMake variable `VS_DEBUGGER_WORKING_DIRECTORY` is defined, then `defaultWorkingDirectory` is set to that value, instead. | `"cwd":"${debugInfo.defaultWorkingDirectory}"` |
 | `fullTargetPath` | The full path to the binary being debugged. | `"program": "${debugInfo.fullTargetPath}"` |
 | `linuxNatvisPath` | The full windows path to the VS linux `.natvis` file. Usually appears as the value `"visualizerFile"`. | |
@@ -98,7 +98,7 @@ The pipeTransport example below shows how to use some of the `debugInfo` macros
         "/c",
         "${debuggerCommand}"
     ]
-    }
+}
 ```
 
 ## <a name="remote_deploy_debug"></a> C++ Windows remote debug and deploy properties
@@ -109,8 +109,8 @@ Used when debugging and deploying an app on a remote machine.
 |--|--|--|
 | `cwd` | string | The working directory of the target on the remote machine. When using CMake, the macro `${debugInfo.defaultWorkingDirectory}` can be used as the value of this field. The default value is the directory of the debug program/command. |
 | `deploy` | string | Specifies extra files or directories to deploy. For example:<br> `"deploy": {"sourcePath":"<Full path to source file/directory on host machine>", "targetPath":"<Full destination path to file/directory on target machine>"}` |
-| `deployDirectory` | string | The location on the remote machine where project outputs are automatically deployed to. Defaults to "`C:\Windows Default Deploy Directory\<name of app>` |
-| `deployDebugRuntimeLibraries` | string | Specifies whether to deploy the debug runtime libraries for the active platform. Defaults to `"true"` if the active configurationType is `"Debug"` |
+| `deployDirectory` | string | The location on the remote machine where project outputs are automatically deployed to. Defaults to `"C:\Windows Default Deploy Directory\<name of app>"`. |
+| `deployDebugRuntimeLibraries` | string | Specifies whether to deploy the debug runtime libraries for the active platform. Defaults to `"true"` if the active configurationType is `"Debug"`. |
 | `deployRuntimeLibraries` | string | Specifies whether to deploy the runtime libraries for the active platform. Defaults to `"true"` if the active configurationType is `"MinSizeRel"`, `"RelWithDebInfo"`, or `"Release"`. |
 | `disableDeploy` | boolean | Specifies whether files should be deployed. |
 | `remoteMachineName` | string | Specifies the name of the remote ARM64 Windows machine where the program is launched. May be the server name or the remote machine's IP address. |

docs/build/prolog-and-epilog.md

@@ -1,8 +1,7 @@
 ---
-description: "Learn more about: x64 prolog and epilog"
 title: "x64 prolog and epilog"
-ms.date: "12/17/2018" 
-ms.assetid: 0453ed1a-3ff1-4bee-9cc2-d6d3d6384984
+description: "Learn more about: x64 prolog and epilog"
+ms.date: 12/17/2018
 ---
 # x64 prolog and epilog
 

docs/build/reference/force-interlocked-functions.md

@@ -1,7 +1,7 @@
 ---
-title:       "/forceInterlockedFunctions"
+title: "/forceInterlockedFunctions"
 description: "Learn more about /forceInterlockedFunctions"
-ms.date:     03/07/2025
+ms.date: 03/07/2025
 ---
 # `/forceInterlockedFunctions`
 

docs/build/reference/fpcvt.md

@@ -1,7 +1,7 @@
 ---
-description: "Learn more about: /fpcvt (Floating-point to integer conversion compatibility)"
 title: "/fpcvt (Floating-point to unsigned integer conversion compatibility)"
-ms.date: 09/25/2025
+description: "Learn more about: /fpcvt (Floating-point to integer conversion compatibility)"
+ms.date: 11/03/2021
 f1_keywords: ["/fpcvt", "-fpcvt"]
 helpviewer_keywords: ["-fpcvt compiler option [C++]", "/fpcvt compiler option [C++]"]
 ---
@@ -42,7 +42,7 @@ The **`/fpcvt`** options are new in Visual Studio 2019 version 16.8. If you spec
 
 ### Intrinsic functions for conversions
 
-You can specify the behavior of a specific conversion independently of the **`/fpcvt `** option, which applies globally. The compiler provides intrinsic sentinel conversion functions for conversions compatible with **`/fpcvt:IA`**. For more information, see [Sentinel conversion functions](../../intrinsics/sentinel-conversion-functions.md). The compiler also provides saturation conversion functions compatible with conversions on ARM or ARM64 target architectures. For more information, see [Saturation conversion functions](../../intrinsics/saturation-conversion-functions.md).
+You can specify the behavior of a specific conversion independently of the **`/fpcvt`** option, which applies globally. The compiler provides intrinsic sentinel conversion functions for conversions compatible with **`/fpcvt:IA`**. For more information, see [Sentinel conversion functions](../../intrinsics/sentinel-conversion-functions.md). The compiler also provides saturation conversion functions compatible with conversions on ARM or ARM64 target architectures. For more information, see [Saturation conversion functions](../../intrinsics/saturation-conversion-functions.md).
 
 The compiler also supports intrinsic conversion functions that execute as quickly as possible for valid conversions. These functions may generate any value or throw an exception for an invalid conversion. The results depend on the target platform, compiler options, and context. They're useful for handling values that have already been range-checked, or values generated in a way that can't cause an invalid conversion. For more information, see [Fast conversion functions](../../intrinsics/fast-conversion-functions.md).
 

docs/build/reference/guard-enable-control-flow-guard.md

@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: /guard (Enable Control Flow Guard)"
 title: "/guard (Enable Control Flow Guard)"
+description: "Learn more about: /guard (Enable Control Flow Guard)"
 ms.date: 2/24/2025
 f1_keywords: ["/guard", "VC.Project.VCCLCompilerTool.ControlFlowGuard"]
 ---
@@ -21,7 +21,7 @@ The **`/guard:cf`** option causes the compiler to analyze control flow for indir
 
 When the **`/guard:cf`** Control Flow Guard (CFG) option is specified, the compiler and linker insert extra runtime security checks to detect attempts to compromise your code. During compiling and linking, all indirect calls in your code are analyzed to find every location that the code can reach when it runs correctly. This information is stored in extra structures in the headers of your binaries. The compiler also injects a check before every indirect call in your code that ensures the target is one of the verified locations. If the check fails at runtime on a CFG-aware operating system, the operating system closes the program.
 
-A common attack on software takes advantage of bugs in handling extreme or unexpected inputs. Carefully crafted input to the application may overwrite a location that contains a pointer to executable code. This technique can be used to redirect control flow to code controlled by the attacker. The CFG runtime checks don't fix the data corruption bugs in your executable. They instead make it more difficult for an attacker to use them to execute arbitrary code. CFG is a mitigation tool that prevents calls to locations other than function entry points in your code. It's similar to how Data Execution Prevention (DEP),  [/GS](gs-buffer-security-check.md) stack checks, and [`/DYNAMICBASE`](dynamicbase-use-address-space-layout-randomization.md) and [/HIGHENTROPYVA](highentropyva-support-64-bit-aslr.md) address space layout randomization (ASLR) lower the chances that your code becomes an exploit vector.
+A common attack on software takes advantage of bugs in handling extreme or unexpected inputs. Carefully crafted input to the application may overwrite a location that contains a pointer to executable code. This technique can be used to redirect control flow to code controlled by the attacker. The CFG runtime checks don't fix the data corruption bugs in your executable. They instead make it more difficult for an attacker to use them to execute arbitrary code. CFG is a mitigation tool that prevents calls to locations other than function entry points in your code. It's similar to how Data Execution Prevention (DEP), [/GS](gs-buffer-security-check.md) stack checks, and [`/DYNAMICBASE`](dynamicbase-use-address-space-layout-randomization.md) and [/HIGHENTROPYVA](highentropyva-support-64-bit-aslr.md) address space layout randomization (ASLR) lower the chances that your code becomes an exploit vector.
 
 To use the CFG exploit mitigation technique, pass **`/guard:cf`** to the compiler and **`/GUARD:CF`** to the linker.