Merge pull request #5730 from MicrosoftDocs/FromPublicMasterBranch

Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main)

Author: Albertyang0

docs/build-insights/tutorials/build-insights-function-view.md

@@ -66,7 +66,7 @@ In the window for the ETL file, choose the **Functions** tab. It shows the funct
 In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.:::
 :::image-end:::
 
-The **Time [sec, %]** column shows how long it took to compile each function in [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism). This metric distributes the wall clock time among functions based on their use of parallel compiler threads. For example, if two different threads are compiling two different functions simultaneously within a one-second period, each function’s WCTR is recorded as 0.5 seconds. This reflects each function’s proportional share of the total compilation time, taking into account the resources each consumed during parallel execution. Thus, WCTR provides a better measure of the impact each function has on the overall build time in environments where multiple compilation activities occur simultaneously.
+The **Time [sec, %]** column shows how long it took to compile each function in [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism). This metric distributes the wall clock time among functions based on their use of parallel compiler threads. For example, if two different threads are compiling two different functions simultaneously within a one-second period, each function's WCTR is recorded as 0.5 seconds. This reflects each function's proportional share of the total compilation time, taking into account the resources each consumed during parallel execution. Thus, WCTR provides a better measure of the impact each function has on the overall build time in environments where multiple compilation activities occur simultaneously.
 
 The **Forceinline Size** column shows roughly how many instructions were generated for the function. Click the chevron before the function name to see the individual inlined functions that were expanded in that function how roughly how many instructions were generated for each.
 

docs/build-insights/tutorials/build-insights-included-files-view.md

@@ -171,7 +171,7 @@ Or, you can right-click a file in the **Include Tree** view to jump to it in the
 - The **Included Files** and **Include Tree** views provide a filter box to find a header file that you're interested in. It does partial matches on the name you provide.
 - Sometimes the parse time reported for a header file is different depending on which file includes it. This can be due to the interplay of different `#define`s that affect which parts of the header are expanded, file caching, and other system factors.
 - If you forget what the **Included Files** or **Include Tree** view is trying to show you, hover over the tab to see a tooltip that describes the view. For example, if you hover over the **Include Tree** tab, the tooltip says: "View that shows include statistics for every file where the children nodes are the files included by the parent node."
-- You may see cases (like `Windows.h`) where the aggregated duration of all the times for a header file is longer than the duration of the entire build. What’s happening is that headers are being parsed on multiple threads at the same time. If two threads simultaneously spend one second parsing a header file, that's 2 seconds of build time even though only one second of wall clock time has gone by. For more information, see [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism).
+- You may see cases (like `Windows.h`) where the aggregated duration of all the times for a header file is longer than the duration of the entire build. What's happening is that headers are being parsed on multiple threads at the same time. If two threads simultaneously spend one second parsing a header file, that's 2 seconds of build time even though only one second of wall clock time has gone by. For more information, see [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism).
 
 ## Troubleshooting
 

docs/c-runtime-library/find-memory-leaks-using-the-crt-library.md

@@ -2,7 +2,7 @@
 title: Find memory leaks with the CRT library
 description: Learn how the C/C++ debugger and C Run-time Library (CRT) can help find memory leaks. The techniques include memory-leak reports and comparing memory snapshots.
 ms.date: 02/03/2023
-helpviewer_keywords: 
+helpviewer_keywords:
   - breakpoints, on memory allocation
   - _CrtMemState
   - _CrtMemCheckpoint
@@ -165,7 +165,7 @@ struct Pod {
     int x;
 };
 
-void main() {
+int main() {
     Pod* pPod = DBG_NEW Pod;
     pPod = DBG_NEW Pod; // Oops, leaked the original pPod!
     delete pPod;

docs/code-quality/c26135.md

@@ -25,14 +25,14 @@ typedef struct _DATA
 void MyEnter(DATA* p)
 {
     // Warning C26135:
-    // Missing side effect annotation _Acquires_lock_(&p->cs)
+    // Missing side effect annotation _Acquires_lock_(p->cs)
     EnterCriticalSection(&p->cs);
 }
 
 void MyLeave(DATA* p)
 {
     // warning C26135:
-    // Missing side effect annotation _Releases_lock_(&p->cs)
+    // Missing side effect annotation _Releases_lock_(p->cs)
     LeaveCriticalSection(&p->cs);
 }
 ```

docs/code-quality/c6387.md

@@ -1,10 +1,9 @@
 ---
-description: "Learn more about: Warning C6387"
 title: Warning C6387
+description: "Learn more about: Warning C6387"
 ms.date: 11/04/2016
 f1_keywords: ["C6387", "INVALID_PARAM_VALUE_1", "__WARNING_INVALID_PARAM_VALUE_1"]
 helpviewer_keywords: ["C6387"]
-ms.assetid: 3ea2fc4d-ffc3-4c3c-bfae-d42aa56235d8
 ---
 # Warning C6387
 
@@ -27,7 +26,7 @@ _Post_ _Null_ char * g();
 
 void f(_In_ char *pch);
 
-void main()
+int main()
 {
     char *pCh = g();
     f(pCh); // Warning C6387
@@ -43,7 +42,7 @@ _Post_ _Notnull_ char * g();
 
 void f(_In_ char *pch);
 
-void main()
+int main()
 {
     char *pCh = g();
     f(pCh);

docs/code-quality/c6394.md

@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: Warning C6394"
 title: Warning C6394
+description: "Learn more about: Warning C6394"
 ms.date: 11/29/2023
 f1_keywords: ["C6394", "LEAP_YEAR_INVALID_DATE_KEYED_LOOKUP_MUTABLE", "__WARNING_LEAP_YEAR_INVALID_DATE_KEYED_LOOKUP_MUTABLE"]
 helpviewer_keywords: ["C6394"]
@@ -52,7 +52,7 @@ void foo(int year)
 
 ## Heuristics
 
-This rule is enforced by checking if a lookup table has an initial size of 365 elements, but can be expanded to 366. However, it doesn't check if the table’s size is adjusted through proper leap year check or not, and so is a low confidence warning.
+This rule is enforced by checking if a lookup table has an initial size of 365 elements, but can be expanded to 366. However, it doesn't check if the table's size is adjusted through proper leap year check or not, and so is a low confidence warning.
 
 ## See also
 

docs/cppcx/fundamental-types-c-cx.md

@@ -1,12 +1,11 @@
 ---
-description: "Learn more about: Fundamental types (C++/CX)"
 title: "Fundamental types (C++/CX)"
+description: "Learn more about: Fundamental types (C++/CX)"
 ms.date: "01/22/2017"
-ms.assetid: c9f82907-25f2-440b-91d6-afb8dbd46ea6
 ---
 # Fundamental types (C++/CX)
 
-In addition to the standard C++ built-in types, C++/CX supports the type system that's defined by the Windows Runtime architecture by providing typedefs for the Windows Runtime fundamental types that map to standard C++ types.. C++/CX implements Boolean, character, and numeric fundamental types. These typedefs are defined in the `default` namespace, which never needs to be specified explicitly. In addition, C++/CX provides wrappers and concrete implementations for certain Windows Runtime types and interfaces.
+In addition to the standard C++ built-in types, C++/CX supports the type system that's defined by the Windows Runtime architecture by providing typedefs for the Windows Runtime fundamental types that map to standard C++ types. C++/CX implements Boolean, character, and numeric fundamental types. These typedefs are defined in the `default` namespace, which never needs to be specified explicitly. In addition, C++/CX provides wrappers and concrete implementations for certain Windows Runtime types and interfaces.
 
 ## Boolean and Character Types
 

docs/ide/include-cleanup-config.md

@@ -56,7 +56,7 @@ The `.editorconfig` settings that you can use with Include Cleanup are:
 |--|--|--|--|
 | `cpp_include_cleanup_add_missing_error_tag_type`</br></br>Sets the error level of add transitive include messages. | `none`</br>`suggestion`</br>`warning`</br>`error` | `cpp_include_cleanup_add_missing_error_tag_type = suggestion` |
 | `cpp_include_cleanup_remove_unused_error_tag_type`</br></br>Sets the error level of remove unused include messages. | `none`</br>`suggestion`</br>`warning`</br>`error`</br>`dimmed` | `cpp_include_cleanup_remove_unused_error_tag_type = dimmed` |
-| `cpp_include_cleanup_excluded_files`</br></br>Excludes the specified files from Include Cleanup messages. You won’t get a suggestion related to the header at all, whether to add it or that it's unused. | *filename* | `cpp_include_cleanup_excluded_files = vcruntime.h, vcruntime_string.h` |
+| `cpp_include_cleanup_excluded_files`</br></br>Excludes the specified files from Include Cleanup messages. You won't get a suggestion related to the header at all, whether to add it or that it's unused. | *filename* | `cpp_include_cleanup_excluded_files = vcruntime.h, vcruntime_string.h` |
 | `cpp_include_cleanup_required_files`</br></br>Specify that usage of *file1* requires *file2*. For example, specify that if you use `atlwin.h` that `altbase.h` must also be included. | *file1*:*file2* | `cpp_include_cleanup_required_files = atlwin.h:altbase.h, atlcom.h:altbase.h` |
 | `cpp_include_cleanup_replacement_files`</br></br>Replaces *file1* with *file2* during Include Cleanup processing. For example, you may prefer using `cstdio` over `stdio.h`. If you have a file with both `#include <cstdio>` and `#include <stdio.h>` and you consume content only from `stdio.h`, with this setting Include Cleanup will tell you to remove `stdio.h` because it replaced the usage of `cstdio` with `stdio.h` during processing. If you don't use the contents from either, Include Cleanup will tell you to remove both.| *file1*:*file2* | `cpp_include_cleanup_replacement_files = stdio.h:cstdio,stdint.h:cstdint` |
 | `cpp_include_cleanup_alternate_files`</br></br>Don't generate a message for indirect include *file2* if *file1* is included. For example, if you `#include <windows.h>` and are only using something from its indirectly included header `winerror.h`, Include Cleanup won't prompt to add `winerror.h`. Useful when you prefer to include a facade header file instead of the indirect includes it contains. | *file1*:*file2* | `cpp_include_cleanup_alternate_files = windows.h:winerror.h, windows.h:minwindef.h` |

docs/ide/lnt-make-member-function-const.md

@@ -8,7 +8,7 @@ monikerRange: ">=msvc-170"
 ---
 # `lnt-make-member-function-const`
 
-When a member function doesn’t modify the object's state, annotate it with the `const` keyword. This guidance comes from the [C++ Core Guideline Con.2](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const).
+When a member function doesn't modify the object's state, annotate it with the `const` keyword. This guidance comes from the [C++ Core Guideline Con.2](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const).
 
 ## Example
 
@@ -19,16 +19,16 @@ class MyClass
 { 
 public: 
 
-  int getValue() { return value; }  // Flagged: ‘getValue’ doesn't modify the object's state. 
-  void setValue(int newValue) { value = newValue; }  // OK: ‘setValue’ modifies the object's state.   
+  int getValue() { return value; }  // Flagged: 'getValue' doesn't modify the object's state. 
+  void setValue(int newValue) { value = newValue; }  // OK: 'setValue' modifies the object's state.   
 
 private: 
 
   int value = 42; 
 }; 
 
 double getRadius()
-{   // Flagged: ‘getRadius’ doesn't modify the object's state. 
+{   // Flagged: 'getRadius' doesn't modify the object's state. 
     return radius; 
 } 
 ```
@@ -45,7 +45,7 @@ class MyClass
 public: 
 
   int getValue() const { return value; }  // Added const 
-  void setValue(int newValue) { value = newValue; }  // OK: ‘setValue’ modifies the object's state.   
+  void setValue(int newValue) { value = newValue; }  // OK: 'setValue' modifies the object's state.   
 
 private: 
 
@@ -54,7 +54,7 @@ private:
 }; 
 
 double getRadius() const // added const
-{   // ‘getRadius’ doesn't modify the object's state. 
+{   // 'getRadius' doesn't modify the object's state. 
     return radius; 
 }  
 ```
@@ -75,4 +75,4 @@ The current implementation of this check allows you to add `const` to member fun
 
 ## See also
 
-[IntelliSense code linter for C++ overview](cpp-linter-overview.md)
+[IntelliSense code linter for C++ overview](cpp-linter-overview.md)