additional scrub for clr:pure and clr:safe per product team (#588)

* additional scrub for clr:pure and clr:safe per product team

* Update pure-and-verifiable-code-cpp-cli.md

Author: mikeblome

docs/build/reference/choosing-the-format-of-netmodule-input-files.md

@@ -21,7 +21,7 @@ An MSIL .obj file (compiled with [/clr](../../build/reference/clr-common-languag
  You can pass an MSIL .obj file to any other Visual Studio compiler via the /addmodule compiler option (but be aware that the .obj file becomes part of the resulting assembly and must be shipped with the assembly).  For example, Visual C# and Visual Basic have the /addmodule compiler option.  
 
 > [!NOTE]
->  In most cases, you will need to pass to the linker the .obj file from the compilation that created the .net module.  One exception to this is if the .netmodule was created with [/clr:pure](../../build/reference/clr-common-language-runtime-compilation.md).  Passing a .dll or .netmodule MSIL module file to the linker may result in LNK1107.  
+>  In most cases, you will need to pass to the linker the .obj file from the compilation that created the .net module.  Passing a .dll or .netmodule MSIL module file to the linker may result in LNK1107.  
   
  .obj files, along with their associated .h files, which you reference via #include in source, allow C++ applications to consume the native types in the module, whereas in a .netmodule file, only the managed types can be consumed by a C++ application.  If you attempt to pass a .obj file to #using, information about native types will not be available; #include the .obj file's .h file instead.  
 
@@ -37,8 +37,6 @@ An MSIL .obj file (compiled with [/clr](../../build/reference/clr-common-languag
 
 -   If your modules will be used to build a managed library, and if all module input to the linker will be verifiable (produced with /clr:safe), use .obj files as module input to the linker and generate a .dll (assembly) or .netmodule (module) library file.  
 
--   If your modules will be used to build a managed library, and if all module input to the linker will be produced with **/clr:pure** or **/clr:safe**, use .obj files as module input to the linker and generate a .dll (assembly) or .netmodule (module) if you only want to expose managed types from the library. The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015. If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library will consist of the .obj files for the libraries component modules (you will also want to ship the .h files for each module, so they can be referenced with #include from source code).  
-  
 -   If your modules will be used to build a managed library, and if one or more modules input to the linker will be produced with just /clr, use .obj files as module input to the linker and generate a .dll (assembly).  If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library will consist of the .obj files for the libraries component modules (you will also want to ship the .h files for each module, so they can be referenced with #include from source code).  
 
 ## See Also  

docs/build/reference/clr-common-language-runtime-compilation.md

@@ -40,17 +40,10 @@ Enables applications and components to use features from the common language run
  [How to: Migrate to /clr](../../dotnet/how-to-migrate-to-clr.md).  
 
  **/clr:pure**  
- Produces a Microsoft Intermediate Language (MSIL)-only output file that has no native executable code. However, it can contain native types compiled to MSIL.  
-  
- For more information, see [Pure and Verifiable Code (C++/CLI)](../../dotnet/pure-and-verifiable-code-cpp-cli.md).  
-  
  /clr:pure is deprecated. A future version of the compiler may not support this option. We recommend that you port code that must be pure MSIL to C#.  
 
  **/clr:safe**  
- Produces an MSIL-only (no native executable code), verifiable output file. **/clr:safe** enables verification diagnostics ([PEVerify Tool (Peverify.exe)](/dotnet/framework/tools/peverify-exe-peverify-tool)).  
-  
-
- /clr:safe is deprecated. A future version of the compiler may not support this option. We recommend that you port code that must be pure, verifiable MSIL to C#.  
+ /clr:safe is deprecated. A future version of the compiler may not support this option. We recommend that you port code that must be safe MSIL to C#. 
 
  **/clr:noAssembly**  
  Specifies that an assembly manifest should not be inserted into the output file. By default, the **noAssembly** option is not in effect.  
@@ -82,7 +75,7 @@ Enables applications and components to use features from the common language run
 
  By default, **/clr** is not in effect. When **/clr** is in effect, **/MD** is also in effect. For more information, see [/MD, /MT, /LD (Use Run-Time Library)](../../build/reference/md-mt-ld-use-run-time-library.md). **/MD** ensures that the dynamically linked, multithreaded versions of the runtime routines are selected from the standard header (.h) files. Multithreading is required for managed programming because the CLR garbage collector runs finalizers in an auxiliary thread.  
 
- If you compile by using **/c**, you can specify the CLR type (IJW, safe, or pure) of the resulting output file with [/CLRIMAGETYPE](../../build/reference/clrimagetype-specify-type-of-clr-image.md).  
+ If you compile by using **/c**, you can specify the CLR type of the resulting output file with [/CLRIMAGETYPE](../../build/reference/clrimagetype-specify-type-of-clr-image.md).  
 
  **/clr** implies **/EHa**, and no other **/EH** options are supported for **/clr**. For more information, see [/EH (Exception Handling Model)](../../build/reference/eh-exception-handling-model.md).  
 
@@ -96,23 +89,6 @@ Enables applications and components to use features from the common language run
 
  The global variables in a native object file are initialized first (during DllMain if the executable is a DLL), and then the global variables in the managed section are initialized (before any managed code is run). `#pragma`[init_seg](../../preprocessor/init-seg.md) only affects the order of initialization in the managed and unmanaged categories.  
 
- Compiling by using **/clr:safe** is analogous to compiling by using [/platform:anycpu](/dotnet/csharp/language-reference/compiler-options/platform-compiler-option) in languages such as C#.  
-  
-## Safe and Pure Images  
- A pure image uses a CLR version of the C run-time (CRT) library. However, the CRT is not verifiable, so you cannot use the CRT when you compile by using **/clr:safe**. For more information, see [CRT Library Features](../../c-runtime-library/crt-library-features.md).  
-  
- Examples of native code that cannot appear in a pure image include inline assembly, [setjmp](../../c-runtime-library/reference/setjmp.md), and [longjmp](../../c-runtime-library/reference/longjmp.md).  
-  
- Every entry point of a pure or safe image is managed. When you compile by using **/clr**, the entry point is native. For more information, see [__clrcall](../../cpp/clrcall.md).  
-  
- When you compile by using **/clr:safe**, by default, variables are [appdomain](../../cpp/appdomain.md) and cannot be per-process. For **/clr:pure**, although **appdomain** is the default, you can use [process](../../cpp/process.md) variables.  
-  
- When running a 32-bit .exe file that was compiled by using **/clr** or **/clr:pure** on a 64-bit operating system, the application will be run under WOW64, which enables a 32-bit application to run on the 32-bit CLR on a 64-bit operating system. By default, an .exe file that is compiled by using **/clr:safe** will be run on the 64-bit CLR on a computer that is running a 64-bit operating system. (On a 32-bit operating system, the same .exe file would run on the 32-bit CLR.) However, a safe application could load a 32-bit component. In that case, a safe image running under operating system 64-bit support will fail when it loads the 32-bit application (BadFormatException). To ensure that a safe image continues to run when it loads a 32-bit image on a 64-bit operating system, you must use [/CLRIMAGETYPE](../../build/reference/clrimagetype-specify-type-of-clr-image.md) to change the metadata (.corflags), and mark it to be run under WOW64. The following command line is an example. (Substitute your own entry symbol.)  
-  
- **cl /clr:safe t.cpp /link /clrimagetype:pure /entry:?main@@$$HYMHXZ /subsystem:console**  
-  
- For information about how to get a decorated name, see [Decorated Names](../../build/reference/decorated-names.md). For more information about 64-bit targets, see [Configure Visual C++ for 64-bit, x64 targets](../../build/configuring-programs-for-64-bit-visual-cpp.md). For information about using pure CLR code, see [How to: Migrate to /clr:pure (C++/CLI)](../../dotnet/how-to-migrate-to-clr-pure-cpp-cli.md) and [Pure and Verifiable Code (C++/CLI)](../../dotnet/pure-and-verifiable-code-cpp-cli.md).  
-  
 ## Metadata and Unnamed Classes  
  Unnamed classes will appear in metadata named as follows: `$UnnamedClass$`*crc-of-current-file-name*`$`*index*`$`, where *index* is a sequential count of the unnamed classes in the compilation. For example, the following code sample generates an unnamed class in metadata.  
 

docs/build/reference/clr-restrictions.md

@@ -55,11 +55,7 @@ Note the following restrictions on the use of **/clr**:
 
     -   **/ZI**  
 
--   The combination of the `_STATIC_CPPLIB` preprocessor definition (`/D_STATIC_CPPLIB`) and the **/clr** or **/clr:pure** compiler option is not supported. This is so because the definition would cause your application to link with the static multithreaded C++ Standard Library, which is not supported. For more information, see the [/MD, /MT, /LD (Use Run-Time Library)](../../build/reference/md-mt-ld-use-run-time-library.md) topic.  
-  
--   [/J](../../build/reference/j-default-char-type-is-unsigned.md) is not supported with **/clr:safe** or **/clr:pure**. The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015.  
-  
--   The ATL and MFC libraries are not supported by pure mode compilation (**/clr:pure**). You can use **/clr:pure** with the C++ Standard Library and the CRT if you also compile with **/MD** or **/MDd**.  
+-   The combination of the `_STATIC_CPPLIB` preprocessor definition (`/D_STATIC_CPPLIB`) and the **/clr** compiler option is not supported. This is so because the definition would cause your application to link with the static multithreaded C++ Standard Library, which is not supported. For more information, see the [/MD, /MT, /LD (Use Run-Time Library)](../../build/reference/md-mt-ld-use-run-time-library.md) topic.  
 
 -   When using **/Zi** with **/clr**, there are performance implications. For more information, see [/Zi](../../build/reference/z7-zi-zi-debug-information-format.md).  
 
@@ -80,8 +76,6 @@ Note the following restrictions on the use of **/clr**:
   
 -   When using the va_arg macro, you may get unexpected results when compiling with **/clr:pure**.  For more information, see [va_arg, va_copy, va_end, va_start](../../c-runtime-library/reference/va-arg-va-copy-va-end-va-start.md).  
   
--   If your application passes an argument of type [va_list](../../c-runtime-library/reference/va-arg-va-copy-va-end-va-start.md) to a function declared to take a variable number of arguments, and your application is compiled with **/clr:pure**, the CLR throws <xref:System.NotSupportedException>. If **/clr**  is used instead, the affected functions are compiled to native code and execute properly. If **/clr:safe** is used, an error diagnostic is emitted.  
-  
 -   You should not call, from managed code, any functions that walk the stack to get parameter information (function arguments); the P/Invoke layer causes that information to be further down the stack.  For example, do not compile proxy/stub with **/clr**.  
   
 -   Functions will be compiled to managed code whenever possible, but not all C++ constructs can be translated to managed code.  This determination is made on a function-by-function basis. If any part of a function cannot be converted to managed code, the entire function will be converted to native code instead. The following cases prevent the compiler from generating managed code.  
@@ -96,7 +90,5 @@ Note the following restrictions on the use of **/clr**:
   
     -   A function that contains references to aligned types, that is, types declared using `__declspec(align(...))`.  
   
--   You cannot use the [Compiler COM Support](../../cpp/compiler-com-support.md) classes with **/clr:pure** or **/clr:safe**.  
-  
 ## See Also  
  [/clr (Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md)

docs/build/reference/clrheader.md

@@ -37,13 +37,9 @@ ms.workload: ["cplusplus"]
 
 -   0  -- /clr (image may contain native code).  
 
--   1 -- /clr:safe (image is MSIL only, able to run on any CLR platform, and possibly verifiable).  
-  
--   3 -- /clr:pure (image is MSIL only, but only able to run on x86 platforms).  
-  
  You can also programmatically check if an image was built for the common language runtime.  For more information, see [How to: Determine if an Image is Native or CLR](../../dotnet/how-to-determine-if-an-image-is-native-or-clr.md).  
 
- The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015.  
+ The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and will be removed in a future version of the compiler. Code that must be "pure" or "safe" should be ported to C#. 
 
 ## See Also  
  [DUMPBIN Options](../../build/reference/dumpbin-options.md)

docs/build/reference/clrimagetype-specify-type-of-clr-image.md

@@ -23,16 +23,10 @@ ms.workload: ["cplusplus"]
 ```  
 
 ## Remarks  
- The linker accepts native objects and also MSIL objects that are compiled by using [/clr](../../build/reference/clr-common-language-runtime-compilation.md), /clr:pure, or /clr:safe. The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015. When mixed objects in the same build are passed, the verifiability of the resulting output file is, by default, equal to the lowest level of verifiability of the input modules. For example, if you pass both a safe and a pure module to the linker, the output file will be pure. If you pass a native image and a mixed mode image (compiled by using **/clr**), the resulting image will be a mixed mode image.  
+ The linker accepts native objects and also MSIL objects that are compiled by using [/clr](../../build/reference/clr-common-language-runtime-compilation.md). The **/clr:pure** and **/clr:safe** compiler options were deprecated in Visual Studio 2015. When mixed objects in the same build are passed, the verifiability of the resulting output file is, by default, equal to the lowest level of verifiability of the input modules. For example, if you pass a native image and a mixed mode image (compiled by using **/clr**), the resulting image will be a mixed mode image.  
 
  You can use /CLRIMAGETYPE to specify a lower level of verifiability, if that is what you need.  
 
- In .NET 4.5, /CLRIMAGETYPE supports a SAFE32BITPREFERRED option. This sets—in the PE header of the image—flags that indicate that the MSIL objects are safe and can be run on all platforms, but that 32-bit execution environments are preferred. This option enables an app to run on ARM platforms and also specifies that it should run under WOW64 on 64-bit operating systems instead of using the 64-bit execution environment.  
-  
- When an .exe that was compiled by using **/clr** or **/clr:pure** is run on a 64-bit operating system, the application is run under WOW64, which enables a 32-bit application to run on a 64-bit operating system. By default, an .exe that's compiled by using **/clr:safe** is run under the operating system's 64-bit support. However, it is possible that your safe application loads a 32-bit component. In that case, a safe image running under the operating system's 64-bit support will fail when it loads the 32-bit application. To ensure that a safe image continues to run when it loads a 32-bit component on a 64-bit operating system, use the /CLRIMAGETYPE:SAFE32BITPREFERRED option. If your code does not have to run on ARM platforms, you can specify the /CLRIMAGETYPE:PURE option to change the metadata (.corflags), marking it to be run under WOW64 (and substituting your own entry symbol):  
-  
- **cl /clr:safe t.cpp /link /clrimagetype:pure /entry:?main@@$$HYMHXZ /subsystem:console**  
-  
  For information about how to determine the CLR image type of a file, see [/CLRHEADER](../../build/reference/clrheader.md).  
 
 ### To set this linker option in the Visual Studio development environment  

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

@@ -29,7 +29,7 @@ ms.workload: ["cplusplus"]
 ## Remarks  
  By default, the linker applies the SuppressUnmanagedCodeSecurityAttribute to linker-generated `PInvoke` calls. When **/CLRUNMANAGEDCODECHECK** is in effect, SuppressUnmanagedCodeSecurityAttribute is not applied.  
 
- The linker only adds the attribute to objects that are compiled with **/clr** or **/clr:pure**. The linker does not generate `PInvoke` calls in objects compiled with **/clr:safe**. For more information, see [/clr (Common Language Runtime Compilation)](../../build/reference/clr-common-language-runtime-compilation.md). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015.  
+ The linker only adds the attribute to objects that are compiled with **/clr** or **/clr:pure**. However, the **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and will be removed in a future version of the compiler.  
 
  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).  
 

docs/build/reference/ltcg-link-time-code-generation.md

@@ -120,11 +120,9 @@ ms.workload: ["cplusplus"]
 ## /LTCG and MSIL Modules  
  Modules that are compiled by using [/GL](../../build/reference/gl-whole-program-optimization.md) and [/clr](../../build/reference/clr-common-language-runtime-compilation.md) can be used as input to the linker when **/LTCG** is specified.  
 
--   **/LTCG** can accept native object files, mixed native/managed object files (compiled by using **/clr**), and pure object files (compiled by using **/clr:pure**), and safe object files (compiled by using **/clr:safe**). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015.  
+-   **/LTCG** can accept native object files, and mixed native/managed object files (compiled by using **/clr**). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015.  
 
--   **/LTCG** can accept safe .netmodules, which can be created by using **/clr:safe /LN** in Visual C++ and **/target:module** in any .NET Visual Studio compiler. .Netmodules produced by using **/clr** or **/clr:pure** are not accepted by **/LTCG**.  
-  
--   /LTCG:PGI does not accept native modules compiled by using **/GL** and **/clr**, or pure modules (produced by using **/clr:pure**)  
+-   /LTCG:PGI does not accept native modules compiled by using **/GL** and **/clr**  
 
 #### To set this compiler option in the Visual Studio development environment