Merge pull request #5348 from Rageking8/fix-inverted-order-of-inline-code-and-italics

Fix inverted order of inline code and italics

Author: v-dirichards

docs/build/clang-support-msbuild.md

@@ -57,7 +57,7 @@ To configure a Visual Studio project to use Clang, right-click on the project no
 The project properties page is open to the Configuration Properties > General page. The Platform Toolset dropdown is selected, on which LLVM (clang-cl) is selected.
 :::image-end:::
 
-If you're using the Clang tools that are bundled with Visual Studio, no extra steps are required. For Windows projects, Visual Studio by default invokes Clang in [clang-cl](https://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf) mode. It links with the Microsoft implementation of the Standard Library. By default, **clang-cl.exe** is located in `*%VCINSTALLDIR%\Tools\Llvm\bin\*` and `*%VCINSTALLDIR%\Tools\Llvm\x64\bin\*`.
+If you're using the Clang tools that are bundled with Visual Studio, no extra steps are required. For Windows projects, Visual Studio by default invokes Clang in [clang-cl](https://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf) mode. It links with the Microsoft implementation of the Standard Library. By default, **clang-cl.exe** is located in *`%VCINSTALLDIR%\Tools\Llvm\bin\`* and *`%VCINSTALLDIR%\Tools\Llvm\x64\bin\`*.
 
 If you're using a custom Clang installation, you can change the value of the `LLVMInstallDir` property. For more information, see [Set a custom LLVM location](#custom_llvm_location).
 

docs/build/reference/arch-arm64.md

@@ -25,7 +25,7 @@ Specifies the Armv9-A architecture, where **`x`** is a required extension value
 You can specify an ARM64 extension from Armv8.0-A through Armv8.9-A, and Armv9.0-A through Armv9.4-A. Optionally, enable one or more architecture features by appending a feature argument to the option<sup>3</sup>. For example, to target Armv8.0-A and enable feature `FEAT_LSE`, append feature argument **`lse`** so that the option becomes **`/arch:armv8.0+lse`**. For more information about available features and their requirements, see [`/feature` (ARM64)](feature-arm64.md)<sup>3</sup>.
 
 > [!NOTE]
-> Depending on your version of Visual Studio, the compiler may not yet generate instructions from all feature sets required by the extension level you specify. For example, **`/arch:armv8.1`** allows the `*Interlocked*` intrinsic functions to use the appropriate atomic instruction introduced with the Armv8.1-A extension feature `FEAT_LSE`, but compiler support requires Visual Studio 2022 version 17.2 or later.
+> Depending on your version of Visual Studio, the compiler may not yet generate instructions from all feature sets required by the extension level you specify. For example, **`/arch:armv8.1`** allows the *`Interlocked`* intrinsic functions to use the appropriate atomic instruction introduced with the Armv8.1-A extension feature `FEAT_LSE`, but compiler support requires Visual Studio 2022 version 17.2 or later.
 
 The `_M_ARM64` macro is defined by default when compiling for an ARM64 target. For more information, see [Predefined macros](../../preprocessor/predefined-macros.md).
 

docs/build/reference/ifc-map.md

@@ -17,7 +17,7 @@ This switch tells the compiler where to find the IFC reference map file, which m
 
 ## Remarks
 
-The `*filename*` argument specifies the IFC reference map file. It can be relative to the compiler's working directory, or an absolute path.
+The *`filename`* argument specifies the IFC reference map file. It can be relative to the compiler's working directory, or an absolute path.
 
 You can provide multiple `/ifcMap` arguments to the compiler.
 

docs/code-quality/c28159.md

@@ -1,14 +1,13 @@
 ---
-description: "Learn more about: Warning C28159"
 title: Warning C28159
+description: "Learn more about: Warning C28159"
 ms.date: 09/08/2022
 f1_keywords: ["C28159", "USE_OTHER_FUNCTION", "__WARNING_USE_OTHER_FUNCTION"]
 helpviewer_keywords: ["C28159"]
-ms.assetid: fab6cd58-0985-4ef6-89a2-64ed04297437
 ---
 # Warning C28159
 
-> Consider using `*function_name_1*` instead of `*function_name_2*`. Reason: *reason*
+> Consider using *`function_name_1`* instead of *`function_name_2`*. Reason: *reason*
 
 This warning occurs when you use a function that is semantically equivalent to an alternative, preferred function call.
 

docs/code-quality/c6331.md

@@ -1,14 +1,13 @@
 ---
-description: "Learn more about: Warning C6331"
 title: Warning C6331
+description: "Learn more about: Warning C6331"
 ms.date: 10/03/2022
 f1_keywords: ["C6331", "VirtualFreeInvalidParam1", "__WARNING_VIRTUALFREEINVALIDPARAM1"]
 helpviewer_keywords: ["C6331"]
-ms.assetid: cb1ecc2c-29a5-4c57-acf2-0954a4c047b1
 ---
 # Warning C6331
 
-> Invalid parameter: passing MEM_RELEASE and MEM_DECOMMIT in conjunction to `*function*` is not allowed. This results in the failure of this call
+> Invalid parameter: passing MEM_RELEASE and MEM_DECOMMIT in conjunction to *`function`* is not allowed. This results in the failure of this call
 
 This message indicates that an invalid parameter is passed to `VirtualFree` or `VirtualFreeEx`. `VirtualFree` and `VirtualFreeEx` both reject the flags (`MEM_RELEASE | MEM_DECOMMIT`) in combination. Therefore, the values `MEM_DECOMMIT` and `MEM_RELEASE` may not be used together in the same call.
 

docs/code-quality/c6383.md

@@ -1,14 +1,13 @@
 ---
-description: "Learn more about: Warning C6383"
 title: Warning C6383
+description: "Learn more about: Warning C6383"
 ms.date: 09/07/2022
 f1_keywords: ["C6383", "ELEMENTS_TO_BYTES", "__WARNING_ELEMENTS_TO_BYTES"]
 helpviewer_keywords: ["C6383"]
-ms.assetid: f5ff7938-0fbe-4b71-b98f-098fe887799d
 ---
 # Warning C6383
 
-> Buffer overrun due to conversion of an element count into a byte count: an element count is expected for parameter `*parameter_name*` in call to `*function_name*`
+> Buffer overrun due to conversion of an element count into a byte count: an element count is expected for parameter *`parameter_name`* in call to *`function_name`*
 
 This warning indicates that a non-constant byte count is being passed when an element count is instead required.
 

docs/error-messages/compiler-errors-1/compiler-error-c2440.md

@@ -1,18 +1,17 @@
 ---
-description: "Learn about type conversion errors that cause Compiler Error C2440."
 title: "Compiler Error C2440"
+description: "Learn about type conversion errors that cause Compiler Error C2440."
 ms.date: 08/27/2021
 f1_keywords: ["C2440"]
 helpviewer_keywords: ["C2440"]
 no-loc: ["struct", "const"]
-ms.assetid: 36e6676c-f04f-4715-8ba1-f096c4bf3b44
 ---
 # Compiler Error C2440
 
 > '*initializing*' : cannot convert from '*type1*' to '*type2*'\
 > '*conversion*' : cannot convert from '*type1*' to '*type2*'
 
-The compiler can't implicitly convert from `*type1*` to `*type2*`, or can't use the specified cast or conversion operator.
+The compiler can't implicitly convert from *`type1`* to *`type2`*, or can't use the specified cast or conversion operator.
 
 ## Remarks
 

docs/error-messages/tool-errors/linker-tools-error-lnk2019.md

@@ -88,9 +88,9 @@ For example, if you use an AVX2 intrinsic, but don't specify the [`/ARCH:AVX2`](
 
 C++ language conformance work that was done in Visual Studio 2005 made **`wchar_t`** a native type by default. If not all files have been compiled by using the same **`/Zc:wchar_t`** settings, type references might not resolve to compatible types. Make sure **`wchar_t`** types in all library and object files are compatible. Either update from a **`wchar_t`** typedef, or use consistent **/Zc:wchar_t** settings when you compile.
 
-### You get errors for `*printf*` and `*scanf*` functions when you link a legacy static library
+### You get errors for *`printf`* and *`scanf`* functions when you link a legacy static library
 
-A static library that was built using a version of Visual Studio before Visual Studio 2015 might cause LNK2019 errors when linked with the UCRT. The UCRT header files `<stdio.h>`, `<conio.h>`, and `<wchar.h>`now define many `*printf*` and `*scanf*` variations as **`inline`** functions. The inlined functions are implemented by a smaller set of common functions. Individual exports for the inlined functions aren't available in the standard UCRT libraries, which only export the common functions. There are a couple of ways to resolve this issue. The method we recommend is to rebuild the legacy library with your current version of Visual Studio. Make sure the library code uses the standard headers for the definitions of the `*printf*` and `*scanf*` functions that caused the errors. Another option for a legacy library that you can't rebuild is to add `legacy_stdio_definitions.lib` to the list of libraries you link. This library file provides symbols for the `*printf*` and `*scanf*` functions that are inlined in the UCRT headers. For more information, see the **Libraries** section in [Overview of potential upgrade issues](../../porting/overview-of-potential-upgrade-issues-visual-cpp.md#libraries).
+A static library that was built using a version of Visual Studio before Visual Studio 2015 might cause LNK2019 errors when linked with the UCRT. The UCRT header files `<stdio.h>`, `<conio.h>`, and `<wchar.h>`now define many *`printf`* and *`scanf`* variations as **`inline`** functions. The inlined functions are implemented by a smaller set of common functions. Individual exports for the inlined functions aren't available in the standard UCRT libraries, which only export the common functions. There are a couple of ways to resolve this issue. The method we recommend is to rebuild the legacy library with your current version of Visual Studio. Make sure the library code uses the standard headers for the definitions of the *`printf`* and *`scanf`* functions that caused the errors. Another option for a legacy library that you can't rebuild is to add `legacy_stdio_definitions.lib` to the list of libraries you link. This library file provides symbols for the *`printf`* and *`scanf`* functions that are inlined in the UCRT headers. For more information, see the **Libraries** section in [Overview of potential upgrade issues](../../porting/overview-of-potential-upgrade-issues-visual-cpp.md#libraries).
 
 ## Third-party library issues and vcpkg
 

docs/standard-library/chrono-operators.md

@@ -668,7 +668,7 @@ The right object to compare.
 1\) Returns **`true`** if the number of ticks for the type common to *`Left`* and *`Right`* are equal. Otherwise, returns **`false`**.\
 2\) Returns **`true`** if *`Left`* and *`Right`* represent the same point in time. Otherwise, returns **`false`**.\
 3-17\) Returns **`true`** if *`Left`* and *`Right`* have the same value. Otherwise, returns **`false`**.\
-18\) Returns **`true`** if `Left.name() == Right.name()`. Otherwise, returns `*false*`.\
+18\) Returns **`true`** if `Left.name() == Right.name()`. Otherwise, returns **`false`**.\
 19\) Returns **`true`** if `Left.get_time_zone() == _Right.get_time_zone() && Left.get_sys_time() == Right.get_sys_time();`
 
 ## <a name="op_gt"></a> `operator>`