9/22/2022 AM Publish (#4536)

* Updated C6101

Mirror of my public PR. Added an example. Added proper spacing between headers and code blocks, matched formatting to my other PRs

* Updated C6101

Minor changes in response to Acrolinx report

* Updated C6101

More Acrolinx changes, split a run-on sentence

* Updated C26495

Matched formatting to my other PRs. Added more information to the example.

* Updated C26495

Fixed spelling error

* Updated C6101

Updated to the latest format

* Updated C6101

Single backticks and InOut->Inout

* Updated C26495

Updated to the new format
NOTE: This warning has no code analysis name. Per @MichaelSquires instructions, I omitted the usual keywords and 'Code analysis name:' section to match

* Update compiler-warning-level-4-c4464.md

@corob-msft 
proposal.  I don't warrant it shouldn't be worded in a better way.

* Update compiler-warning-level-4-c4464.md

typo fix

* fix: delete unnecessary asterisk

followup fix of MicrosoftDocs#4136

* optimize prime test

* Update floating-point-support.md

Explain what "ulp" stands for

* Updates for cpp-docs 4161

* Update integritycheck-require-signature-check.md

* alt-text

* Update abstract-cpp-component-extensions.md

* Add syntax highlighting to atl-mfc-shared

* Updated C26495

Added code analysis ID

* alt-text updates

* customer fix

* minor updates

* Incorporate changes in rewrite

Updates for style and clarity. Also give it an Acrolinx pass.

* Clarify version support

* Tweak language for minimum support

* Add code style, comment

@MugBergerFries 
It's a good idea to use code styling for mentions of variable or class names (especially when they're easily confused generic names like "value").
I also added a comment to the fixed code sample to amplify the change and what it was doing.

* acrolinx

* cleanup pass

* [BULK] DocuTune - Rebranding

* alt-text updates

* update alt-text

* Update README.md

* Address cpp-docs 4149 __umulh on ARM64

* Add slashes per cpp-docs 4150

* update alt-text code and removed 'experimental' from images

* Update clang-support-msbuild.md

Updated for better visibility of LLVMToolsVersion property.

Note the text was also misleading because it kind of implies that LLVMToolsVersion supports side-by-side version of clang/LLVM in the same `LLVMInstallDir`, but that's not how clang/LLVM works. If you want to select a different version, you need to point it to a different path.

* test fix

* test fix

* test fix

* alt-text updates plus acrolinx

* acrolinx

* Split props file and IDE sections

When both path and version are merged in the .props file discussion, a division between the .props approach and the IDE approach seems more natural than repeating the same content twice.

* Update to add /std requirement

* Test of build checks features

* Update cpp-linter-overview.md

* Provide F1 links to articles for VS linker properties (#4529)

* Update F1 links for Linker Properties

* F1 Project: Linker Properties part 1

* Finish Linker properties F1 links

* Fix typo

* Fix acrolinx related issues

Co-authored-by: Samuel Berger <[email protected]>
Co-authored-by: Brad Litterell <[email protected]>
Co-authored-by: opbld17 <[email protected]>
Co-authored-by: Colin Robertson <[email protected]>
Co-authored-by: opbld16 <[email protected]>
Co-authored-by: Kisaragi <[email protected]>
Co-authored-by: Courtney Wales <[email protected]>
Co-authored-by: opbld15 <[email protected]>
Co-authored-by: TylerMSFT <[email protected]>
Co-authored-by: Bryan Gold <[email protected]>
Co-authored-by: Edward Breeveld <[email protected]>
Co-authored-by: Jeff Borsecnik <[email protected]>
Co-authored-by: jsuther1974 <[email protected]>
Co-authored-by: Austin Morton <[email protected]>
Co-authored-by: Jak Koke <[email protected]>
Co-authored-by: HO-COOH <[email protected]>
Co-authored-by: prmerger-automator[bot] <40007230+prmerger-automator[bot]@users.noreply.github.com>
Co-authored-by: James Barnett <[email protected]>
Co-authored-by: Dennis Rea <[email protected]>
Co-authored-by: Alex Buck <[email protected]>
Co-authored-by: Tyler Whitney <[email protected]>
Co-authored-by: Feng Xu <[email protected]>
Co-authored-by: Chuck Walbourn <[email protected]>
Co-authored-by: Colin Cooper <[email protected]>

Author: 25 people

docs/build/clang-support-msbuild.md

@@ -1,31 +1,31 @@
 ---
 description: "Learn more about: Clang/LLVM support in Visual Studio projects"
 title: "Clang/LLVM support in Visual Studio projects"
-ms.date: 06/29/2022
+ms.date: 09/20/2022
 ms.description: "Configure a Visual Studio MSBuild project to use the Clang/LLVM toolchain."
 helpviewer_keywords: ["Clang support for C++ MSBuild projects"]
 ---
 # Clang/LLVM support in Visual Studio projects
 
 ::: moniker range="<=msvc-150"
 
-Clang support for both CMake and MSBuild projects is available in Visual Studio 2019.
+Clang/LLVM support for both CMake and MSBuild projects is available in Visual Studio 2019 and Visual Studio 2022.
 
 ::: moniker-end
 
 ::: moniker range=">=msvc-160"
 
-You can use Visual Studio 2019 version 16.2 and later with Clang to edit, build, and debug C++ Visual Studio projects (MSBuild) that target Windows or Linux.
+You can use Visual Studio 2019 version 16.2 and later with Clang/LLVM to edit, build, and debug C++ Visual Studio projects (MSBuild) that target Windows or Linux.
 
 ## Install
 
-For best IDE support in Visual Studio, we recommend using the latest Clang compiler tools for Windows. If you don't already have the tools, you can install them by opening the Visual Studio Installer and choosing **C++ Clang tools for Windows** under **Desktop development with C++** optional components. You may prefer to use an existing Clang installation on your machine; if so, choose **C++ Clang-cl for v142 build tools**.
+For best IDE support in Visual Studio, we recommend using the latest Clang compiler tools for Windows. If you don't already have the tools, you can install them by opening the Visual Studio Installer and choosing **C++ Clang tools for Windows** under **Desktop development with C++** optional components. You may prefer to use an existing Clang installation on your machine; if so, choose **C++ Clang-cl for v142 build tools** or **C++ Clang-cl for v143 build tools**.
 
 The Microsoft C++ Standard Library requires at least Clang 8.0.0.
 
 ![Screenshot of the Visual Studio installer with the Individual components tab selected and the C plus plus Clang components visible.](media/clang-install-vs2019.png)
 
-Later versions of Visual Studio provide newer versions of the Clang toolset. The bundled version of Clang gets updated automatically to stay current with updates in the Microsoft implementation of the Standard Library. For example, Visual Studio 2019 version 16.9 includes Clang v11.
+Later versions of Visual Studio provide newer versions of the Clang toolset. The bundled version of Clang gets updated automatically to stay current with updates in the Microsoft implementation of the Standard Library. For example, Visual Studio 2019 version 16.11 includes Clang v12.
 
 ## Configure a Windows project to use Clang tools
 
@@ -52,58 +52,36 @@ To configure a Visual Studio Linux project to use Clang:
 
 On Linux, Visual Studio by default uses the first Clang location that it finds in the PATH environment property. If you're using a custom Clang installation, then either change the value of the `LLVMInstallDir` property or else enter the path under **Project** > **Properties** > **Configuration Properties** > **VC++ DIrectories** > **Executable Directories**. For more information, see [Set a custom LLVM location](#custom_llvm_location).
 
-## <a name="custom_llvm_location"></a> Set a custom LLVM location
+## <a name="custom_llvm_location"></a> Set a custom LLVM location and toolset
 
-You can set a custom path to LLVM for one or more projects by creating a *Directory.build.props* file. Then, add that file to the root folder of any project. You can add it to the root solution folder to apply it to all projects in the solution. The file should look like this (but use your actual LLVM path):
+To set a custom path to LLVM and set a custom LLVM toolset version for one or more projects, create a *Directory.build.props* file. Then, add that file to the root folder of any project. You can add it to the root solution folder to apply it to all projects in the solution. The file should look like this example (but use your actual LLVM path and version number):
 
 ```xml
 <Project>
   <PropertyGroup>
     <LLVMInstallDir>C:\MyLLVMRootDir</LLVMInstallDir>
+    <LLVMToolsVersion>15.0.0</LLVMToolsVersion>
   </PropertyGroup>
 </Project>
 ```
 
-You can combine this property with a custom LLVM toolset version. For more information, see [Set a custom LLVM toolset version](#custom_llvm_toolset).
+## <a name="custom_llvm_toolset"></a> Set a custom LLVM toolset version in the IDE
 
-## <a name="custom_llvm_toolset"></a> Set a custom LLVM toolset version
+Starting in Visual Studio 2019 version 16.9, you can set a custom toolset version for LLVM in Visual Studio. To set this property in a project:
 
-Starting in Visual Studio 2019 version 16.9, you can set a custom toolset version for LLVM. To set this property in a project in Visual Studio:
-
-1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](./working-with-project-properties.md).
+1. Open the project's **Property Pages** dialog box. For more information, see [Set C++ compiler and build properties](./working-with-project-properties.md).
 
 1. Select the **Configuration Properties** > **General** property page.
 
-1. Modify the **Platform Toolset** property to *LLVM (clang-cl)*, if it isn't already set.
+1. Modify the **Platform Toolset** property to *LLVM (clang-cl)*, if it isn't already set. Choose **Apply** to save your changes.
 
 1. Select the **Configuration Properties** > **Advanced** property page.
 
 1. Modify the **LLVM Toolset Version** property to your preferred version, and then choose **OK** to save your changes.
 
 The **LLVM Toolset Version** property only appears when the LLVM platform toolset is selected.
 
-You can set the toolset version for one or more projects by creating a *Directory.build.props* file. Then, add that file to the root folder of any project. Add it to the root solution folder to apply it to all projects in the solution. The file should look like this (but use your actual LLVM path):
-
-```xml
-<Project>
-  <PropertyGroup>
-    <LLVMToolsVersion>11.0.0</LLVMToolsVersion>
-  </PropertyGroup>
-</Project>
-```
-
-You can also combine this property with a custom LLVM location. For example, your *Directory.build.props* file could look like:
-
-```xml
-<Project>
-  <PropertyGroup>
-    <LLVMInstallDir>C:\MyLLVMRootDir</LLVMInstallDir>
-    <LLVMToolsVersion>11.0.0</LLVMToolsVersion>
-  </PropertyGroup>
-</Project>
-```
-
-When you add a *Directory.build.props* file, the settings appear as the default in the project Property Pages dialog. However, changes to these properties in Visual Studio override the settings in the *Directory.build.props* file.
+When you add a *Directory.build.props* file to a project or solution, the settings appear as the default in the project Property Pages dialog. However, changes to these properties in Visual Studio override the settings in the *Directory.build.props* file.
 
 ## Set additional properties, edit, build, and debug
 

docs/build/reference/cetcompat.md

@@ -2,12 +2,12 @@
 description: "Learn more about: /CETCOMPAT (CET Shadow Stack compatible)"
 title: "/CETCOMPAT (CET Shadow Stack compatible)"
 ms.date: 09/22/2021
-f1_keywords: ["/CETCOMPAT"]
+f1_keywords: ["VC.Project.VCLinkerTool.CETCompat", "/CETCOMPAT"]
 helpviewer_keywords: ["/CETCOMPAT linker option", "/CETCOMPAT"]
 ---
-# /CETCOMPAT (CET Shadow Stack compatible)
+# `/CETCOMPAT` (CET Shadow Stack compatible)
 
-Specifies whether to mark an executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack.
+Specifies whether the linker marks an executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack.
 
 ## Syntax
 
@@ -21,7 +21,7 @@ Specifies that the executable shouldn't be marked compatible with CET Shadow Sta
 
 ## Remarks
 
-Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature. It provides capabilities to defend against return-oriented programming (ROP) based malware attacks. For more information, see [A Technical Look at Intel’s Control-flow Enforcement Technology](https://software.intel.com/content/www/us/en/develop/articles/technical-look-control-flow-enforcement-technology.html).
+Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature. It provides capabilities to defend against return-oriented programming (ROP) based malware attacks. For more information, see [A Technical Look at Intel's Control-flow Enforcement Technology](https://software.intel.com/content/www/us/en/develop/articles/technical-look-control-flow-enforcement-technology.html).
 
 The **`/CETCOMPAT`** linker option tells the linker to mark the binary as CET Shadow Stack-compatible. **`/CETCOMPAT:NO`** marks the binary as not compatible with CET Shadow Stack. If both options are specified on the command line, the last one specified is used. This switch is currently only applicable to x86 and x64 architectures.
 
@@ -31,7 +31,7 @@ The **`/CETCOMPAT`** option is available beginning in Visual Studio 2019.
 
 Starting in Visual Studio 2019 version 16.7:
 
-1. Open the **Property Pages** dialog box for the project. For more information, see [Working with Project Properties](../working-with-project-properties.md).
+1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
 
 1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
 
@@ -41,7 +41,7 @@ Starting in Visual Studio 2019 version 16.7:
 
 In previous versions of Visual Studio 2019:
 
-1. Open the **Property Pages** dialog box for the project. For more information, see [Working with Project Properties](../working-with-project-properties.md).
+1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
 
 1. Select the **Configuration Properties** > **Linker** > **Command Line** property page.
 

docs/build/reference/clrsupportlasterror-preserve-last-error-code-for-pinvoke-calls.md

@@ -1,39 +1,39 @@
 ---
 description: "Learn more about: /CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)"
 title: "/CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)"
-ms.date: "11/04/2016"
-f1_keywords: ["/CLRSUPPORTLASTERROR"]
+ms.date: 09/19/2022
+f1_keywords: ["VC.Project.VCLinkerTool.CLRSupportLastError", "/CLRSUPPORTLASTERROR"]
 helpviewer_keywords: ["/CLRSUPPORTLASTERROR linker option", "-CLRSUPPORTLASTERROR linker option"]
 ms.assetid: b7057990-4154-4b1d-9fc9-6236f7be7575
 ---
-# /CLRSUPPORTLASTERROR (Preserve Last Error Code for PInvoke Calls)
+# `/CLRSUPPORTLASTERROR` (Preserve Last Error Code for PInvoke Calls)
 
-**/CLRSUPPORTLASTERROR**, which is on by default, preserves the last error code of functions called through the P/Invoke mechanism, which allows you to call native functions in DLLS, from code compiled with **/clr**.
+**`/CLRSUPPORTLASTERROR`**, which is on by default, preserves the last error code of functions called through the P/Invoke mechanism, which allows you to call native functions in DLLS, from code compiled with **`/clr`**.
 
 ## Syntax
 
-```
-/CLRSUPPORTLASTERROR{:NO | SYSTEMDLL}
-```
+> **`/CLRSUPPORTLASTERROR`**\
+> **`/CLRSUPPORTLASTERROR:NO`**\
+> **`/CLRSUPPORTLASTERROR:SYSTEMDLL`**
 
 ## Remarks
 
-Preserving the last error code implies a decrease in performance.  If you do not want to incur the performance impact of preserving the last error code, link with  **/CLRSUPPORTLASTERROR:NO**.
+Preserving the last error code implies a decrease in performance.  If you don't want to incur the performance cost of preserving the last error code, link by using **`/CLRSUPPORTLASTERROR:NO`**.
 
-You can minimize the performance impact by linking with **/CLRSUPPORTLASTERROR:SYSTEMDLL**, which only preserves the last error code for functions in system DLLs.
+You can minimize the performance penalty by linking with **`/CLRSUPPORTLASTERROR:SYSTEMDLL`**, which only preserves the last error code for functions in system DLLs.
 
 > [!NOTE]
-> Preserving the last error is not supported for unmanaged functions that are consumed by CLR code, in the same module.
+> Preserving the last error isn't supported for unmanaged functions that are consumed by CLR code in the same module.
 
-- For more information, see [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md).
+- For more information, see [`/clr` (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md).
 
 ### To set this linker option in the Visual Studio development environment
 
-1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](../working-with-project-properties.md).
+1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
 
-1. Select the **Configuration Properties** > **Linker** > **Command Line** property page.
+1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
 
-1. Enter the option into the **Additional Options** box.
+1. Modify the **Preserve Last Error Code for PInvoke Calls** property. Choose **OK** or **Apply** to save your changes.
 
 ### To set this linker option programmatically
 
@@ -56,7 +56,7 @@ __declspec(dllexport) double MySqrt(__int64 n) {
 }
 ```
 
-The following sample consumes the DLL, demonstrating how to use **/CLRSUPPORTLASTERROR**.
+The following sample consumes the DLL, demonstrating how to use **`/CLRSUPPORTLASTERROR`**.
 
 ```cpp
 // CLRSUPPORTLASTERROR_client.cpp
@@ -109,5 +109,5 @@ GetLastError for system call succeeded (183).
 
 ## See also
 
-[MSVC linker reference](linking.md)<br/>
-[MSVC Linker Options](linker-options.md)
+[MSVC linker reference](linking.md)\
+[MSVC linker options](linker-options.md)

docs/build/reference/clrunmanagedcodecheck-add-suppressunmanagedcodesecurityattribute.md

@@ -1,37 +1,38 @@
 ---
 description: "Learn more about: /CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)"
 title: "/CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)"
-ms.date: "05/16/2019"
+ms.date: 09/19/2022
 ms.topic: "reference"
-f1_keywords: ["/CLRUNMANAGEDCODECHECK"]
+f1_keywords: ["VC.Project.VCLinkerTool.CLRUnmanagedCodeCheck", "/CLRUNMANAGEDCODECHECK"]
 helpviewer_keywords: ["-CLRUNMANAGEDCODECHECK linker option", "/CLRUNMANAGEDCODECHECK linker option"]
 ms.assetid: 73abc426-dab0-45e2-be85-0f9a14206cc2
 author: "corob-msft"
 ms.author: "corob"
 ---
-# /CLRUNMANAGEDCODECHECK (Remove SuppressUnmanagedCodeSecurityAttribute)
+# `/CLRUNMANAGEDCODECHECK` (Remove SuppressUnmanagedCodeSecurityAttribute)
 
-**/CLRUNMANAGEDCODECHECK** specifies that the linker does not apply <xref:System.Security.SuppressUnmanagedCodeSecurityAttribute> to linker-generated `PInvoke` calls from managed code into native DLLs.
+**`/CLRUNMANAGEDCODECHECK`** specifies that the linker doesn't apply <xref:System.Security.SuppressUnmanagedCodeSecurityAttribute> to linker-generated `PInvoke` calls from managed code into native DLLs.
 
 ## Syntax
 
-> **/CLRUNMANAGEDCODECHECK**[**:NO**]
+> **`/CLRUNMANAGEDCODECHECK`**\
+> **`/CLRUNMANAGEDCODECHECK:NO`**
 
 ## Remarks
 
-By default, the linker applies the **SuppressUnmanagedCodeSecurityAttribute** to linker-generated `PInvoke` calls. When **/CLRUNMANAGEDCODECHECK** is in effect, **SuppressUnmanagedCodeSecurityAttribute** is removed. To explicitly apply the **SuppressUnmanagedCodeSecurityAttribute** to linker-generated `PInvoke` calls, you can use **/CLRUNMANAGEDCODECHECK:NO**.
+By default, the linker applies the `SuppressUnmanagedCodeSecurityAttribute` attribute to linker-generated `PInvoke` calls. When **`/CLRUNMANAGEDCODECHECK`** is in effect, `SuppressUnmanagedCodeSecurityAttribute` is removed. To explicitly apply the `SuppressUnmanagedCodeSecurityAttribute` attribute to linker-generated `PInvoke` calls, you can use **`/CLRUNMANAGEDCODECHECK:NO`**.
 
-The linker only adds the attribute to objects that are compiled using **/clr** or **/clr:pure**. However, the **/clr:pure** compiler option is deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later.
+The linker only adds the attribute to objects that are compiled using **`/clr`** or **`/clr:pure`**. However, the **`/clr:pure`** compiler option is deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017 and later.
 
-A `PInvoke` call is generated by the linker when the linker cannot find a managed symbol to satisfy a reference from a managed caller but can find a native symbol to satisfy that reference. For more information about `PInvoke`, see [Calling Native Functions from Managed Code](../../dotnet/calling-native-functions-from-managed-code.md).
+A `PInvoke` call is generated by the linker when the linker can't find a managed symbol to satisfy a reference from a managed caller but can find a native symbol to satisfy that reference. For more information about `PInvoke`, see [Calling Native Functions from Managed Code](../../dotnet/calling-native-functions-from-managed-code.md).
 
-Note that if you use <xref:System.Security.AllowPartiallyTrustedCallersAttribute> in your code, you should explicitly set **/CLRUNMANAGEDCODECHECK** to remove the **SuppressUnmanagedCodeSecurity** attribute. It is a potential security vulnerability if an image contains both the **SuppressUnmanagedCodeSecurity** and **AllowPartiallyTrustedCallers** attributes.
+If you use <xref:System.Security.AllowPartiallyTrustedCallersAttribute> in your code, you should explicitly set **`/CLRUNMANAGEDCODECHECK`** to remove the `SuppressUnmanagedCodeSecurity` attribute. It's a potential security vulnerability if an image contains both the `SuppressUnmanagedCodeSecurity` and `AllowPartiallyTrustedCallers` attributes.
 
-See [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/framework/windows-identity-foundation/secure-coding-guidelines-for-unmanaged-code) for more information about the implications of using **SuppressUnmanagedCodeSecurityAttribute**.
+For more information about the implications of using `SuppressUnmanagedCodeSecurityAttribute`, see [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/framework/windows-identity-foundation/secure-coding-guidelines-for-unmanaged-code).
 
 ### To set this linker option in the Visual Studio development environment
 
-1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](../working-with-project-properties.md).
+1. Open the **Property Pages** dialog box for the project. For more information, see [Set compiler and build properties](../working-with-project-properties.md).
 
 1. Select the **Configuration Properties** > **Linker** > **Advanced** property page.
 
@@ -43,5 +44,5 @@ See [Secure Coding Guidelines for Unmanaged Code](/previous-versions/dotnet/fram
 
 ## See also
 
-- [MSVC linker reference](linking.md)
-- [MSVC Linker Options](linker-options.md)
+[MSVC linker reference](linking.md)\
+[MSVC linker options](linker-options.md)