Merge pull request #2098 from MicrosoftDocs/master637224836453453829

Fix git push error for protected CLA branch

Author: Colin Robertson

docs/build/configure-cmake-debugging-sessions.md

@@ -34,7 +34,7 @@ You can customize the debugger settings for any executable CMake target in your
 
 - **Targets View:** Navigate to **Targets View** in Solution Explorer. Then, right-click on a debug target and select **Add Debug Configuration** to customize the debug configuration specific to the selected target.
 
-![Targets view entry point](media/cmake-targets-add-debug.png "Targets view entry point")
+![Targets view entry point](media/cmake-targets-add-debug-configuration.png "Targets view entry point")
 
 - **Root CMakeLists.txt:** Right-click on a root *CMakeLists.txt* and select **Add Debug Configuration** to open the **Select a Debugger** dialog box. The dialog allows you to add *any* type of debug configuration, but you must manually specify the CMake target to invoke via the `projectTarget` property.
 

docs/build/media/cmake-targets-add-debug.PNG renamed to docs/build/media/cmake-targets-add-debug-configuration.png

@@ -1,6 +1,7 @@
 ---
 title: "/permissive- (Standards conformance)"
-ms.date: "03/08/2019"
+description: "Reference guide to the Microsoft C++ /permissive- (Standards conformance) compiler option."
+ms.date: "04/14/2020"
 f1_keywords: ["/permissive", "VC.Project.VCCLCompilerTool.ConformanceMode"]
 helpviewer_keywords: ["/permissive compiler options [C++]", "-permissive compiler options [C++]", "Standards conformance compiler options", "permissive compiler options [C++]"]
 ms.assetid: db1cc175-6e93-4a2e-9396-c3725d2d8f71
@@ -19,7 +20,7 @@ This option is supported in Visual Studio 2017 and later.
 
 You can use the **/permissive-** compiler option to specify standards-conforming compiler behavior. This option disables permissive behaviors, and sets the [/Zc](zc-conformance.md) compiler options for strict conformance. In the IDE, this option also makes the IntelliSense engine underline non-conforming code.
 
-By default, the **/permissive-** option is set in new projects created by Visual Studio 2017 version 15.5 and later versions. It is not set by default in earlier versions. When the option is set, the compiler generates diagnostic errors or warnings when non-standard language constructs are detected in your code, including some common bugs in pre-C++11 code.
+By default, the **/permissive-** option is set in new projects created by Visual Studio 2017 version 15.5 and later versions. It's not set by default in earlier versions. When the option is set, the compiler generates diagnostic errors or warnings when non-standard language constructs are detected in your code, including some common bugs in pre-C++11 code.
 
 The **/permissive-** option is compatible with almost all of the header files from the latest Windows Kits, such as the Software Development Kit (SDK) or Windows Driver Kit (WDK), starting in the Windows Fall Creators SDK (10.0.16299.0). Older versions of the SDK may fail to compile under **/permissive-** for various source code conformance reasons. The compiler and SDKs ship on different release timelines, therefore there are some remaining issues. For specific header file issues, see [Windows header issues](#windows-header-issues) below.
 
@@ -29,7 +30,7 @@ In versions of the compiler beginning in Visual Studio 2017 version 15.3, the **
 
 Environment-specific extensions and language areas that the standard leaves up to the implementation are not affected by **/permissive-**. For example, the Microsoft-specific `__declspec`, calling convention and structured exception handling keywords, and compiler-specific pragma directives or attributes are not flagged by the compiler in **/permissive-** mode.
 
-The **/permissive-** option uses the conformance support in the current compiler version to determine which language constructs are non-conforming. The option does not determine if your code conforms to a specific version of the C++ standard. To enable all implemented compiler support for the latest draft standard, use the [/std:latest](std-specify-language-standard-version.md) option. To restrict the compiler support to the currently implemented C++17 standard, use the [/std:c++17](std-specify-language-standard-version.md) option. To restrict the compiler support to more closely match the C++14 standard, use the [/std:c++14](std-specify-language-standard-version.md) option, which is the default.
+The **/permissive-** option uses the conformance support in the current compiler version to determine which language constructs are non-conforming. The option doesn't determine if your code conforms to a specific version of the C++ standard. To enable all implemented compiler support for the latest draft standard, use the [/std:latest](std-specify-language-standard-version.md) option. To restrict the compiler support to the currently implemented C++17 standard, use the [/std:c++17](std-specify-language-standard-version.md) option. To restrict the compiler support to more closely match the C++14 standard, use the [/std:c++14](std-specify-language-standard-version.md) option, which is the default.
 
 Not all C++11, C++14, or C++17 standards-conforming code is supported by the MSVC compiler in all versions of Visual Studio 2017. Depending on the version of Visual Studio, the **/permissive-** option may not detect issues regarding some aspects of two-phase name lookup, binding a non-const reference to a temporary, treating copy init as direct init, allowing multiple user-defined conversions in initialization, or alternative tokens for logical operators, and other non-supported conformance areas. For more information about conformance issues in Visual C++, see [Nonstandard Behavior](../../cpp/nonstandard-behavior.md). To get the most out of **/permissive-**, update Visual Studio to the latest version.
 
@@ -121,7 +122,7 @@ void g() {
     f(nullptr); // error C3861: 'f': identifier not found
 
     S *p = nullptr;
-    f(S); // Hidden friend now found via argument-dependent lookup.
+    f(p); // Hidden friend now found via argument-dependent lookup.
 }
 ```
 
@@ -255,7 +256,7 @@ auto y = cond ? 7 : int(a);
 auto z = cond ? A(7) : a;
 ```
 
-There is an important exception to this common pattern when T represents one of the null-terminated string types (for example, `const char *`, `const char16_t *`, and so on) and the actual argument to `?:` is a string literal of corresponding type. C++17 has changed semantics from C++14. As a result, the code in example 2 is accepted under **/std:c++14** and rejected under **/std:c++17** when **/Zc:ternary** or **/permissive-** is used.
+There's an important exception to this common pattern when T represents one of the null-terminated string types (for example, `const char *`, `const char16_t *`, and so on) and the actual argument to `?:` is a string literal of corresponding type. C++17 has changed semantics from C++14. As a result, the code in example 2 is accepted under **/std:c++14** and rejected under **/std:c++17** when **/Zc:ternary** or **/permissive-** is used.
 
 ```cpp
 // Example 2: exception from the above
@@ -301,7 +302,7 @@ const char (&z)[2] = count > 3 ? "A" : "B"; // const char* without /Zc:ternary
 
 #### Two-phase name look-up
 
-When the **/permissive-** option is set, the compiler parses function and class template definitions, identifying dependent and non-dependent names used in templates as required for two-phase name look-up. In Visual Studio 2017 version 15.3, name dependency analysis is performed. In particular, non-dependent names that are not declared in the context of a template definition cause a diagnostic message as required by the ISO C++ standards. In Visual Studio 2017 version 15.7, binding of non-dependent names that require argument-dependent look-up in the definition context is also done.
+When the **/permissive-** option is set, the compiler parses function and class template definitions, identifying dependent and non-dependent names used in templates as required for two-phase name look-up. In Visual Studio 2017 version 15.3, name dependency analysis is performed. In particular, non-dependent names that aren't declared in the context of a template definition cause a diagnostic message as required by the ISO C++ standards. In Visual Studio 2017 version 15.7, binding of non-dependent names that require argument-dependent look-up in the definition context is also done.
 
 ```cpp
 // dependent base
@@ -335,7 +336,7 @@ The **/permissive-** option is too strict for versions of the Windows Kits befor
 
 Certain header files in the Windows April 2018 Update SDK (10.0.17134.0), the Windows Fall Creators Update SDK (10.0.16299.0), or the Windows Driver Kit (WDK) 1709, still have issues that make them incompatible with use of **/permissive-**. To work around these issues, we recommend you restrict the use of these headers to only those source code files that require them, and remove the **/permissive-** option when you compile those specific source code files.
 
-These WinRT WRL headers released in the Windows April 2018 Update SDK (10.0.17134.0) are not clean with **/permissive-**. To work around these issues, either do not use **/permissive-**, or use **/permissive-** with **/Zc:twoPhase-** when working with these headers:
+These WinRT WRL headers released in the Windows April 2018 Update SDK (10.0.17134.0) aren't clean with **/permissive-**. To work around these issues, either do not use **/permissive-**, or use **/permissive-** with **/Zc:twoPhase-** when you work with these headers:
 
 - Issues in winrt/wrl/async.h
 
@@ -352,7 +353,7 @@ These WinRT WRL headers released in the Windows April 2018 Update SDK (10.0.1713
    C:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\winrt\wrl\implements.h(2086): error C2039: 'SetStrongReference': is not a member of 'Microsoft::WRL::Details::WeakReferenceImpl'
    ```
 
-These User Mode headers released in the Windows April 2018 Update SDK (10.0.17134.0) are not clean with **/permissive-**. To work around these issues, do not use **/permissive-** when working with these headers:
+These User Mode headers released in the Windows April 2018 Update SDK (10.0.17134.0) aren't clean with **/permissive-**. To work around these issues, don't use **/permissive-** when working with these headers:
 
 - Issues in um/Tune.h
 
@@ -381,7 +382,7 @@ These issues are specific to User Mode headers in the Windows Fall Creators Upda
 
 - Issue in um/Query.h
 
-   When using the **/permissive-**  compiler switch, the `tagRESTRICTION` structure does not compile due to the case(RTOr) member 'or'.
+   When using the **/permissive-**  compiler switch, the `tagRESTRICTION` structure doesn't compile because of the case(RTOr) member 'or'.
 
    ```cpp
    struct tagRESTRICTION