Merge pull request #2777 from MicrosoftDocs/master

3/31/2020 AM Publish

Author: Taojunshen

docs/build/cmakesettings-reference.md

@@ -139,6 +139,7 @@ When the active configuration specifies a Visual Studio generator, by default MS
 ```
 
 Note that if you do not define the `"type"`, the `"STRING"` type will be assumed by default.
+
 - `remoteCopyOptimizations`: **Visual Studio 2019 version 16.5 or later** properties for controlling source copy to the remote target. Optimizations are enabled by default. Includes `remoteCopyUseOptimizations`, `rsyncSingleDirectoryCommandArgs`, and `remoteCopySourcesMaxSmallChange`.
 
 ## <a name="environments"></a> Environments

docs/build/get-started-linux-cmake.md

@@ -11,6 +11,7 @@ Visual Studio C and C++ development isn't just for Windows anymore. This tutoria
 In this tutorial, you learn how to:
 
 > [!div class="checklist"]
+>
 > * clone an open-source CMake project from GitHub
 > * open the project in Visual Studio
 > * build and debug an executable target on Windows

docs/build/how-to-organize-project-output-files-for-builds.md

@@ -38,7 +38,7 @@ This topic describes best practices for organizing project output files. Build e
 
 1. Reference the appropriate header file in your code using the #include directive. The header file must be in the include path or part of the current project. For more information, see [#include Directive (C/C++)](../preprocessor/hash-include-directive-c-cpp.md).
 
-1. You can also set project dependencies. Setting project dependencies guarantees two things. First, it ensures that projects are built in the right order so that a project can always find the dependent files it needs. Second, it implicitly adds the dependent project’s output directory to the path so that files can be found easily at link-time.
+1. You can also set project dependencies. Setting project dependencies guarantees two things. First, it ensures that projects are built in the right order so that a project can always find the dependent files it needs. Second, it implicitly adds the dependent project's output directory to the path so that files can be found easily at link-time.
 
 1. To deploy the application, you will need to place the DLL in an appropriate place. This can be one of the following:
 

docs/build/open-folder-projects-cpp.md

@@ -172,7 +172,7 @@ For more information, see [Tasks.vs.json schema reference](tasks-vs-json-schema-
 
 ### Configure debugging parameters with launch.vs.json
 
-To customize your program’s command line arguments and debugging instructions, right-click on the executable in **Solution Explorer** and select **Debug and Launch Settings**. This will open an existing *launch.vs.json* file, or if none exists, it will create a new file with a set of minimal launch settings. First you are given a choice of what kind of debug session you want to configure. For debugging a MinGw-w64 project, we choose **C/C++ Launch for MinGW/Cygwin (gdb)**. This creates a launch configuration for using *gdb.exe* with some educated guesses about default values. One of those default values is `MINGW_PREFIX`. You can substitute the literal path (as shown below) or you can define a `MINGW_PREFIX` property in *CppProperties.json*:
+To customize your program's command line arguments and debugging instructions, right-click on the executable in **Solution Explorer** and select **Debug and Launch Settings**. This will open an existing *launch.vs.json* file, or if none exists, it will create a new file with a set of minimal launch settings. First you are given a choice of what kind of debug session you want to configure. For debugging a MinGw-w64 project, we choose **C/C++ Launch for MinGW/Cygwin (gdb)**. This creates a launch configuration for using *gdb.exe* with some educated guesses about default values. One of those default values is `MINGW_PREFIX`. You can substitute the literal path (as shown below) or you can define a `MINGW_PREFIX` property in *CppProperties.json*:
 
 ```json
 {

docs/build/optimization-best-practices.md

@@ -26,7 +26,7 @@ The **/Gy** switch is also very useful. It generates a separate COMDAT for each
 
 For linking in 64-bit environments, it is recommended to use the **/OPT:REF,ICF** linker option, and in 32-bit environments, **/OPT:REF** is recommended. For more information, see [/OPT (Optimizations)](reference/opt-optimizations.md).
 
-It is also strongly recommended to generate debug symbols, even with optimized release builds. It doesn’t affect the generated code, and it makes it a lot easier to debug your application, if need be.
+It is also strongly recommended to generate debug symbols, even with optimized release builds. It doesn't affect the generated code, and it makes it a lot easier to debug your application, if need be.
 
 ### Floating-point switches
 
@@ -61,7 +61,7 @@ For more information, see [noalias](../cpp/noalias.md).
 
 ## Optimization pragmas
 
-There are also several useful pragmas for helping optimize code. The first one we’ll discuss is `#pragma optimize`:
+There are also several useful pragmas for helping optimize code. The first one we'll discuss is `#pragma optimize`:
 
 ```cpp
 #pragma optimize("{opt-list}", on | off)
@@ -81,7 +81,7 @@ Inlining is one of the most important optimizations that the compiler performs a
 
 `#pragma inline_recursion` is useful for specifying whether or not you want the application to be able to inline a recursive call. By default it is off. For shallow recursion of small functions you may to turn this on. For more information, see [inline_recursion](../preprocessor/inline-recursion.md).
 
-Another useful pragma for limiting the depth of inlining is `#pragma inline_depth`. This is typically useful in situations where you’re trying to limit the size of a program or function. For more information, see [inline_depth](../preprocessor/inline-depth.md).
+Another useful pragma for limiting the depth of inlining is `#pragma inline_depth`. This is typically useful in situations where you're trying to limit the size of a program or function. For more information, see [inline_depth](../preprocessor/inline-depth.md).
 
 ## __restrict and \__assume
 

docs/build/overview-of-arm-abi-conventions.md

@@ -203,7 +203,7 @@ Windows code is compiled with frame pointers enabled ([/Oy (Frame-Pointer Omissi
 
 ## Exception unwinding
 
-Stack unwinding during exception handling is enabled by the use of unwind codes. The unwind codes are a sequence of bytes stored in the .xdata section of the executable image. They describe the operation of the function prologue and epilogue code in an abstract manner, so that the effects of a function’s prologue can be undone in preparation for unwinding to the caller’s stack frame.
+Stack unwinding during exception handling is enabled by the use of unwind codes. The unwind codes are a sequence of bytes stored in the .xdata section of the executable image. They describe the operation of the function prologue and epilogue code in an abstract manner, so that the effects of a function's prologue can be undone in preparation for unwinding to the caller's stack frame.
 
 The ARM EABI specifies an exception unwinding model that uses unwind codes. However, this specification is not sufficient for unwinding in Windows, which must handle cases where the processor is in the middle of the prologue or epilogue of a function. For more information about Windows on ARM exception data and unwinding, see [ARM Exception Handling](arm-exception-handling.md).
 

docs/build/prolog-and-epilog.md

@@ -81,7 +81,7 @@ In practice, when a frame pointer is used, there is no good reason to adjust RSP
     ret
 ```
 
-These forms are the only legal ones for an epilog. It must consist of either an `add RSP,constant` or `lea RSP,constant[FPReg]`, followed by a series of zero or more 8-byte register pops and a `return` or a `jmp`. (Only a subset of `jmp` statements are allowable in the epilog. The subset is exclusively the class of `jmp` statements with ModRM memory references where ModRM mod field value is 00. The use of `jmp` statements in the epilog with ModRM mod field value 01 or 10 is prohibited. See Table A-15 in the AMD x86-64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions, for more info on the allowable ModRM references.) No other code can appear. In particular, nothing can be scheduled within an epilog, including loading of a return value.
+These forms are the only legal ones for an epilog. It must consist of either an `add RSP,constant` or `lea RSP,constant[FPReg]`, followed by a series of zero or more 8-byte register pops and a `return` or a `jmp`. (Only a subset of `jmp` statements are allowable in the epilog. The subset is exclusively the class of `jmp` statements with ModRM memory references where ModRM mod field value is 00. The use of `jmp` statements in the epilog with ModRM mod field value 01 or 10 is prohibited. See Table A-15 in the AMD x86-64 Architecture Programmer's Manual Volume 3: General Purpose and System Instructions, for more info on the allowable ModRM references.) No other code can appear. In particular, nothing can be scheduled within an epilog, including loading of a return value.
 
 When a frame pointer is not used, the epilog must use `add RSP,constant` to deallocate the fixed part of the stack. It may not use `lea RSP,constant[RSP]` instead. This restriction exists so the unwind code has fewer patterns to recognize when searching for epilogs.
 

docs/build/reference/description-blocks.md

@@ -201,7 +201,7 @@ This dependency line shows how to create a directory specification for a search:
 reverse.exe : {\src\omega;e:\repo\backwards}retro.obj
 ```
 
-The target `reverse.exe` has one dependent, `retro.obj`. The brace-enclosed list specifies two directories. NMAKE searches for `retro.obj` in the current directory first. If it isn’t there, NMAKE searches the `\src\omega` directory, then the `e:\repo\backwards` directory.
+The target `reverse.exe` has one dependent, `retro.obj`. The brace-enclosed list specifies two directories. NMAKE searches for `retro.obj` in the current directory first. If it isn't there, NMAKE searches the `\src\omega` directory, then the `e:\repo\backwards` directory.
 
 ## See also
 

docs/build/reference/eh-exception-handling-model.md

@@ -37,7 +37,7 @@ If you use **/EHs** or **/EHsc**, then your `catch(...)` clause does not catch a
 
 If you use **/EHa**, the image may be larger and might perform less well because the compiler does not optimize a **try** block as aggressively. It also leaves in exception filters that automatically call the destructors of all local objects even if the compiler does not see any code that can throw a C++ exception. This enables safe stack unwinding for asynchronous exceptions as well as for C++ exceptions. When you use **/EHs**, the compiler assumes that exceptions can only occur at a **throw** statement or at a function call. This allows the compiler to eliminate code for tracking the lifetime of many unwindable objects, and this can significantly reduce code size.
 
-We recommend that you not link objects compiled by using **/EHa** together with objects compiled by using **/EHs** or **/EHsc** in the same executable module. If you have to handle an asynchronous exception by using **/EHa** anywhere in your module, use **/EHa** to compile all the code in the module. You can use structured exception handling syntax in the same module as code that's compiled by using **/EHs**, but you can’t mix the SEH syntax with **try**, **throw**, and **catch** in the same function.
+We recommend that you not link objects compiled by using **/EHa** together with objects compiled by using **/EHs** or **/EHsc** in the same executable module. If you have to handle an asynchronous exception by using **/EHa** anywhere in your module, use **/EHa** to compile all the code in the module. You can use structured exception handling syntax in the same module as code that's compiled by using **/EHs**, but you can't mix the SEH syntax with **try**, **throw**, and **catch** in the same function.
 
 Use **/EHa** if you want to catch an exception that's raised by something other than a **throw**. This example generates and catches a structured exception:
 

docs/build/reference/exports.md

@@ -47,7 +47,7 @@ Because the MSVC compiler uses name decoration for C++ functions, you must eithe
 
 To find the decorated names produced by the compiler, use the [DUMPBIN](dumpbin-reference.md) tool or the linker [/MAP](map-generate-mapfile.md) option. The decorated names are compiler-specific. If you export the decorated names in the .DEF file, executables that link to the DLL must also be built by using the same version of the compiler. This ensures that the decorated names in the caller match the exported names in the .DEF file.
 
-You can use \@*ordinal* to specify that a number, and not the function name, goes into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.
+You can use \@*ordinal* to specify that a number, and not the function name, goes into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don't recommend exporting functions by ordinal unless your DLL's clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.
 
 By using the optional **NONAME** keyword, you can export by ordinal only and reduce the size of the export table in the resulting DLL. However, if you want to use [GetProcAddress](/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress) on the DLL, you must know the ordinal because the name will not be valid.
 

docs/build/reference/hint-files.md

@@ -23,6 +23,7 @@ A hint file contains user-customizable hints, which have the same syntax as C/C+
 
 > [!IMPORTANT]
 > If you modify or add a hint file, you need to take additional steps in order for the changes to take effect:
+>
 > - In versions before Visual Studio 2017 version 15.6: Delete the .sdf file and/or VC.db file in the solution for all changes.
 > - In Visual Studio 2017 version 15.6 and later: Close and reopen the solution after adding new hint files.
 

docs/build/reference/linking.md

@@ -40,7 +40,7 @@ On the command line, an option consists of an option specifier, either a dash (-
 
 To pass a file to the linker, specify the filename on the command line after the LINK command. You can specify an absolute or relative path with the filename, and you can use wildcards in the filename. If you omit the dot (.) and filename extension, LINK assumes .obj for the purpose of finding the file. LINK does not use filename extensions or the lack of them to make assumptions about the contents of files; it determines the type of file by examining it, and processes it accordingly.
 
-link.exe returns zero for success (no errors).  Otherwise, the linker returns the error number that stopped the link.  For example, if the linker generates LNK1104, the linker returns 1104.  Accordingly, the lowest error number returned on an error by the linker is 1000.  A return value of 128 represents a configuration problem with either the operating system or a .config file; the loader didn’t load either link.exe or c2.dll.
+link.exe returns zero for success (no errors).  Otherwise, the linker returns the error number that stopped the link.  For example, if the linker generates LNK1104, the linker returns 1104.  Accordingly, the lowest error number returned on an error by the linker is 1000.  A return value of 128 represents a configuration problem with either the operating system or a .config file; the loader didn't load either link.exe or c2.dll.
 
 ## LINK Command Files
 

docs/build/reference/makefile-preprocessing-operators.md

@@ -24,7 +24,7 @@ Expressions can use the following operators. The operators of equal precedence a
 |**EXIST(** *path* **)**|Produces a logical value for the existence of a file at *path*.|
 |||
 |**!**|Unary logical NOT.|
-|**~**|Unary one’s complement.|
+|**~**|Unary one's complement.|
 |**-**|Unary negation.|
 |||
 |*****|Multiplication.|

docs/build/reference/manifestinput-specify-manifest-input.md

@@ -22,7 +22,7 @@ The manifest file to include in the embedded manifest.
 
 The **/MANIFESTINPUT** option specifies the path of an input file to use to create the embedded manifest in an executable image. If you have multiple manifest input files, use the switch multiple times—once for each input file. The manifest input files are merged to create the embedded manifest. This option requires the **/MANIFEST:EMBED** option.
 
-This option can’t be set directly in Visual Studio. Instead, use the **Additional Manifest Files** property of the project to specify additional manifest files to include. For more information, see [Manifest Tool Property Pages](manifest-tool-property-pages.md).
+This option can't be set directly in Visual Studio. Instead, use the **Additional Manifest Files** property of the project to specify additional manifest files to include. For more information, see [Manifest Tool Property Pages](manifest-tool-property-pages.md).
 
 ## See also
 

docs/build/reference/openmp-enable-openmp-2-0-support.md

@@ -43,7 +43,7 @@ These exceptions can also be raised in the following situations:
 
 - If you pass your **/clr** app to a utility, such as [regasm.exe](/dotnet/framework/tools/regasm-exe-assembly-registration-tool), which loads its target assemblies into a non-default application domain.
 
-The common language runtime's code access security doesn’t work in OpenMP regions. If you apply a CLR code access security attribute outside a parallel region, it won't be in effect in the parallel region.
+The common language runtime's code access security doesn't work in OpenMP regions. If you apply a CLR code access security attribute outside a parallel region, it won't be in effect in the parallel region.
 
 Microsoft doesn't recommend that you write **/openmp** apps that allow partially trusted callers. Don't use <xref:System.Security.AllowPartiallyTrustedCallersAttribute>, or any CLR code access security attributes.
 

docs/build/reference/opt-optimizations.md

@@ -42,7 +42,7 @@ In a debug build, you must explicitly specify **/OPT:ICF** to enable COMDAT fold
 
 **LBR** | **NOLBR**
 
-The **/OPT:LBR** and **/OPT:NOLBR** options apply only to ARM binaries. Because certain ARM processor branch instructions have a limited range, if the linker detects a jump to an out-of-range address, it replaces the branch instruction’s destination address with the address of a code "island" that contains a branch instruction that targets the actual destination. You can use **/OPT:LBR** to optimize the detection of long branch instructions and the placement of intermediate code islands to minimize overall code size. **/OPT:NOLBR** instructs the linker to generate code islands for long branch instructions as they are encountered, without optimization.
+The **/OPT:LBR** and **/OPT:NOLBR** options apply only to ARM binaries. Because certain ARM processor branch instructions have a limited range, if the linker detects a jump to an out-of-range address, it replaces the branch instruction's destination address with the address of a code "island" that contains a branch instruction that targets the actual destination. You can use **/OPT:LBR** to optimize the detection of long branch instructions and the placement of intermediate code islands to minimize overall code size. **/OPT:NOLBR** instructs the linker to generate code islands for long branch instructions as they are encountered, without optimization.
 
 By default, the **/OPT:LBR** option is set when incremental linking is not enabled. If you want a non-incremental link but not long branch optimizations, specify **/OPT:NOLBR**. The **/OPT:LBR** option disables incremental linking.