Merge pull request #4664 from MicrosoftDocs/main638264210302381116sync_temp

For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error

Author: learn-build-service-prod[bot]

docs/build/modify-project-properties-without-changing-project-file.md

@@ -1,7 +1,7 @@
 ---
 description: "Learn more about: How to: Modify C++ project properties and targets without changing the project file"
 title: "How to: Modify C++ project properties and targets without changing the project file"
-ms.date: "11/28/2018"
+ms.date: "7/28/2023"
 helpviewer_keywords: ["project properties [C++], modifying outside project file"]
 ---
 # How to: Modify C++ project properties and targets without changing the project file
@@ -13,27 +13,27 @@ You can override project properties and targets from the MSBuild command prompt
 
 *To override project properties:*
 
-1. Create a .props file that specifies the properties you want to override.
+1. Create a `.props` file that specifies the properties you want to override.
 
-1. From the command prompt: set ForceImportBeforeCppTargets="C:\sources\my_props.props"
+1. From the command prompt: `set ForceImportBeforeCppTargets="C:\sources\my_props.props"`
 
 *To override project targets:*
 
-1. Create a .targets file with their implementation or a particular target
+1. Create a `.targets` file with their implementation or a particular target
 
-2. From the command prompt: set ForceImportAfterCppTargets ="C:\sources\my_target.targets"
+2. From the command prompt: `set ForceImportAfterCppTargets ="C:\sources\my_target.targets"`
 
-You can also set either option on the msbuild command line by using the /p: option:
+You can also set either option on the msbuild command line by using the `/p:` option:
 
 ```cmd
-> msbuild myproject.sln /p:ForceImportBeforeCppTargets="C:\sources\my_props.props"
-> msbuild myproject.sln /p:ForceImportAfterCppTargets="C:\sources\my_target.targets"
+msbuild myproject.sln /p:ForceImportBeforeCppTargets="C:\sources\my_props.props"
+msbuild myproject.sln /p:ForceImportAfterCppTargets="C:\sources\my_target.targets"
 ```
 
-Overriding properties and targets in this way is equivalent to adding the following imports to all .vcxproj files in the solution:
+Overriding properties and targets in this way is equivalent to adding the following imports to all `.vcxproj` files in the solution:
 
-```cmd
-<Import Project=="C:\sources\my_props.props" />
+```xml
+<Import Project="C:\sources\my_props.props" />
 <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
-<Import Project==" C:\sources\my_target.targets"" />
+<Import Project="C:\sources\my_target.targets" />
 ```

docs/cpp/modules-cpp.md

@@ -6,7 +6,7 @@ description: Modules in C++20 provide a modern alternative to header files.
 ---
 # Overview of modules in C++
 
-C++20 introduces *modules*, a modern solution that turns C++ libraries and programs into components. A *module* is a set of source code files that are compiled independently of the source files (or more precisely, the [translation units](https://wikipedia.org/wiki/Translation_unit_(programming)) that import them. Modules eliminate or reduce many of the problems associated with the use of header files. They often reduce compilation times. Macros, preprocessor directives, and non-exported names declared in a module aren't visible outside the module. They have no effect on the compilation of the translation unit that imports the module. You can import modules in any order without concern for macro redefinitions. Declarations in the importing translation unit don't participate in overload resolution or name lookup in the imported module. After a module is compiled once, the results are stored in a binary file that describes all the exported types, functions, and templates. The compiler can process that file much faster than a header file. And, the compiler can reuse it every place where the module is imported in a project.
+C++20 introduces *modules*, a modern solution that turns C++ libraries and programs into components. A *module* is a set of source code files that are compiled independently of the source files (or more precisely, the [translation units](https://wikipedia.org/wiki/Translation_unit_(programming)) that import them). Modules eliminate or reduce many of the problems associated with the use of header files. They often reduce compilation times. Macros, preprocessor directives, and nonexported names declared in a module aren't visible outside the module. They have no effect on the compilation of the translation unit that imports the module. You can import modules in any order without concern for macro redefinitions. Declarations in the importing translation unit don't participate in overload resolution or name lookup in the imported module. After a module is compiled once, the results are stored in a binary file that describes all the exported types, functions, and templates. The compiler can process that file much faster than a header file. And, the compiler can reuse it every place where the module is imported in a project.
 
 You can use modules side by side with header files. A C++ source file can `import` modules and also `#include` header files. In some cases, you can import a header file as a module, which is faster than using `#include` to process it with the preprocessor. We recommend that you use modules in new projects rather than header files as much as possible. For larger existing projects under active development, experiment with converting legacy headers to modules. Base your adoption on whether you get a meaningful reduction in compilation times.
 
@@ -16,7 +16,7 @@ To contrast modules with other ways to import the standard library, see [Compare
 
 As of Visual Studio 2022 version 17.1, C++20 standard modules are fully implemented in the Microsoft C++ compiler.
 
-Before it was specified by the C++20 standard, Microsoft had experimental support for modules. The compiler also supported importing pre-built Standard Library modules, described below.
+Before it was specified by the C++20 standard, Microsoft had experimental support for modules. The compiler also supported importing prebuilt Standard Library modules, described below.
 
 Starting with Visual Studio 2022 version 17.5, importing the Standard Library as a module is both standardized and fully implemented in the Microsoft C++ compiler. This section describes the older, experimental method, which is still supported. For information about the new standardized way to import the Standard Library using modules, see [Import the C++ standard library using modules](tutorial-import-stl-named-module.md).
 
@@ -129,7 +129,7 @@ The **`export`** keyword is used in interface files only. An implementation file
 
 ## Modules, namespaces, and argument-dependent lookup
 
-The rules for namespaces in modules are the same as in any other code. If a declaration within a namespace is exported, the enclosing namespace (excluding non-exported members) is also implicitly exported. If a namespace is explicitly exported, all declarations within that namespace definition are exported.
+The rules for namespaces in modules are the same as in any other code. If a declaration within a namespace is exported, the enclosing namespace (excluding nonexported members) is also implicitly exported. If a namespace is explicitly exported, all declarations within that namespace definition are exported.
 
 When it does argument-dependent lookup for overload resolutions in the importing translation unit, the compiler considers functions declared in the same translation unit (including module interfaces) as where the type of the function's arguments are defined.