Fix trailing whitespaces (dotnet#40891)

* Trim trailing whitespaces

* Match raw with rendered

* Delete extra asterisks and |

* Update ELT Hooks - tail calls.md

Co-authored-by: Jan Kotas <[email protected]>

SECURITY.md

@@ -6,8 +6,8 @@ The .NET Core and ASP.NET Core support policy, including supported versions can
 
 ## Reporting a Vulnerability
 
-Security issues and bugs should be reported privately to the Microsoft Security Response Center (MSRC), either by emailing [email protected] or via the portal at https://msrc.microsoft.com. 
-You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your 
+Security issues and bugs should be reported privately to the Microsoft Security Response Center (MSRC), either by emailing [email protected] or via the portal at https://msrc.microsoft.com.
+You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your
 original message. Further information, including the MSRC PGP key, can be found in the [MSRC Report an Issue FAQ](https://www.microsoft.com/en-us/msrc/faqs-report-an-issue).
 
 Reports via MSRC may qualify for the .NET Core Bug Bounty. Details of the .NET Core Bug Bounty including terms and conditions are at [https://aka.ms/corebounty](https://aka.ms/corebounty).

docs/coding-guidelines/api-guidelines/System.Memory.md

@@ -51,4 +51,4 @@ specs can be found here:
   can be implicitly converted to `ReadOnlySpan<T>`.
 * **AVOID** providing overloads for both `ReadOnlySpan<T>`/`Span<T>` as well as
   pointers and arrays as those can be implicitly converted to
-  `ReadOnlySpan<T>`/`Span<T>`.
+  `ReadOnlySpan<T>`/`Span<T>`.

docs/coding-guidelines/api-guidelines/nullability.md

@@ -114,7 +114,7 @@ A code review for enabling nullability generally involves three passes:
     - Adding `!` to reference type usage.  These essentially suppress the null warning, telling the compiler to treat the expression as if it's non-null.  These evaporate at compile-time.
 
     - Adding `Debug.Assert(reference != null);` statements.  These inform the compiler that the mentioned reference is non-`null`, which will cause the compiler to factor that in and have the effect of suppressing subsequent warnings on that reference (until the flow analysis suggests that could change).  As with any `Debug.Assert`, these evaporate at compile-time in release builds (where `DEBUG` isn't defined).
-  
+
   - Most any other changes have the potential to change the IL, which should not be necessary for the feature.  In particular, it's common for `?`s on dereferences to sneak in, e.g. changing `someVar.SomeMethod()` to `someVar?.SomeMethod()`; that is a change to the IL, and should only be employed when there's an actual known bug that's important to fix, as otherwise we're incurring unnecessary cost.  Similarly, it's easy to accidentally add `?` to value types, which has a significant impact, changing the `T` to a `Nullable<T>` and should be avoided.
 
   - Any `!`s added that should have been unnecessary and are required due to either a compiler issue or due to lack of expressibility about annotations should have a `// TODO-NULLABLE: http://link/to/relevant/issue` comment added on the same line.

docs/coding-guidelines/breaking-change-definitions.md

@@ -6,7 +6,7 @@ Behavioral Change
 
 A behavioral change represents changes to the behavior of a member. A behavioral change may including throwing a new exception, adding or removing internal method calls, or alternating the way in which a return value is calculated. Behavioral changes can be the hardest type of change to categorize as acceptable or not - they can be severe in impact, or relatively innocuous.
 
-Binary Compatibility  
+Binary Compatibility
 --------------------
 
 Refers to the ability of existing consumers of an API to be able to use a newer version without recompilation. By definition, if an assembly's public signatures have been removed, or altered so that consumers can no longer access the same interface exposed by the assembly, the change is said to be a _binary incompatible change_.
@@ -16,19 +16,19 @@ Source Compatibility
 
 Refers to the ability of existing consumers of an API to recompile against a newer version without any source changes. By definition, if a consumer needs to make changes to its code in order for it to build successfully against a newer version of an API, the change is said to be a _source incompatible change_.
 
-Design-Time Compatibility  
+Design-Time Compatibility
 -------------------------
 
 _Design-time compatibility_ refers to preserving the design-time experience across versions of Visual Studio and other design-time environments. This can involve details around the UI of the designer, but by far the most interesting design-time compatibility is project compatibility. A potential project (or solution), must be able to be opened, and used on a newer version of a designer.
 
-Backwards Compatibility  
+Backwards Compatibility
 -----------------------
 
-_Backwards compatibility_ refers to the ability of an existing consumer of an API to run against, and behave in the same way against a newer version. By definition, if a consumer is not able to run, or behaves differently against the newer version of the API, then the API is said to be _backwards incompatible_. 
+_Backwards compatibility_ refers to the ability of an existing consumer of an API to run against, and behave in the same way against a newer version. By definition, if a consumer is not able to run, or behaves differently against the newer version of the API, then the API is said to be _backwards incompatible_.
 
 Changes that affect backwards compatibility are strongly discouraged. All alternates should be actively considered, since developers will, by default, expect backwards compatibility in newer versions of an API.
 
-Forwards Compatibility  
+Forwards Compatibility
 ----------------------
 
 _Forwards compatibility_ is the exact reverse of backwards compatibility; it refers to the ability of an existing consumer of an API to run against, and behave in the way against a _older_ version. By definition, if a consumer is not able to run, or behaves differently against an older version of the API, then the API is said to be _forwards incompatible_.

docs/coding-guidelines/breaking-change-rules.md

@@ -19,14 +19,14 @@ Breaking Change Rules
 ### Property, Field, Parameter and Return Values
 ✓ **Allowed**
 * Increasing the range of accepted values for a property or parameter if the member _is not_ `virtual`
- 
+
     Note that the range can only increase to the extent that it does not impact the static type. e.g. it is OK to remove `if (x > 10) throw new ArgumentOutOfRangeException("x")`, but it is not OK to change the type of `x` from `int` to `long` or `int?`.
 
 * Returning a value of a more derived type for a property, field, return or `out` value
 
     Note, again, that the static type cannot change. e.g. it is OK to return a `string` instance where an `object` was returned previously, but it is not OK to change the return type from `object` to `string`.
 
-✗ **Disallowed**  
+✗ **Disallowed**
 * Increasing the range of accepted values for a property or parameter if the member _is_ `virtual`
 
     This is breaking because any existing overridden members will now not function correctly for the extended range of values.
@@ -135,7 +135,7 @@ Breaking Change Rules
     So long as it does not introduce any new abstract members or change the semantics or behavior of existing members, a type can be introduced into a hierarchy between two existing types. For example, between .NET Framework 1.1 and .NET Framework 2.0, we introduced `DbConnection` as a new base class for `SqlConnection` which previously derived from `Component`.
 
 * Adding an interface implementation to a type
-    
+
     This is acceptable because it will not adversely affect existing clients. Any changes which could be made to the type being changed in this situation, will have to work within the boundaries of acceptable changes defined here, in order for the new implementation to remain acceptable.
     Extreme caution is urged when adding interfaces that directly affect the ability of the designer or serializer to generate code or data, that cannot be consumed down-level. An example is the `ISerializable` interface.
     Care should be taken when the interface (or one of the interfaces that this interface requires) has default interface implementations for other interface methods. The default implementation could conflict with other default implementations in a derived class.
@@ -205,7 +205,7 @@ Breaking Change Rules
 
 * Adding an overload that precludes an existing overload, and defines different behavior
 
-    This will break existing clients that were bound to the previous overload. For example, if you have a class that has a single version of a method that accepts a `uint`, an existing consumer will 
+    This will break existing clients that were bound to the previous overload. For example, if you have a class that has a single version of a method that accepts a `uint`, an existing consumer will
 successfully bind to that overload, if simply passing an `int` value. However, if you add an overload that accepts an `int`, recompiling or via late-binding the application will now bind to the new overload. If different behavior results, then this is a breaking change.
 
 * Moving an exposed field onto a class higher in the hierarchy tree of the type from which it was removed

docs/coding-guidelines/breaking-changes.md

@@ -97,7 +97,7 @@ more latitude here in .NET Core.
 
 For buckets #2 and #3 we apply a risk-benefit analysis. It doesn't matter if the
 old behavior is "wrong", we still need to think through the implications. This
-can result in one of the following outcomes: 
+can result in one of the following outcomes:
 
 * **Accepted with compat switch**. Depending on the estimated customer impact,
   we may decide to add a compat switch that allows consumers to bring back the

docs/coding-guidelines/interop-guidelines.md

@@ -58,7 +58,7 @@ internal static partial class Interop
 ```
 
 As shown above, platforms may be additive, in that an assembly may use functionality from multiple folders, e.g. System.IO.FileSystem's Linux build will use functionality both from Unix (common across all Unix systems) and from Linux (specific to Linux and not available across non-Linux Unix systems).
-			 
+
 - Interop.*.cs files are created in a way such that every assembly consuming the file will need every DllImport it contains.
   - If multiple related DllImports will all be needed by every consumer, they may be declared in the same file, named for the functionality grouping, e.g. Interop.IOErrors.cs.
   - Otherwise, in the limit (and the expected case for most situations) each Interop.*.cs file will contain a single DllImport and associated interop types (e.g. the structs used with that signature) and helper wrappers, e.g. Interop.strerror.cs.
@@ -104,7 +104,7 @@ internal static partial class Interop // contents of Common\src\Interop\Windows\
 
 ```
 (Note that this will likely result in some extra constants defined in each assembly that uses interop, which minimally violates one of the goals, but it's very minimal.)
-			 
+
 - .csproj project files then include the interop code they need, e.g.
 ```XML
 <ItemGroup Condition=" '$(TargetsUnix)' == 'true' ">
@@ -170,10 +170,10 @@ To address this, we're moving to a model where all UNIX interop from dotnet/runt
 
 Guidelines for shim C++ API:
 
-- Keep them as "thin"/1:1 as possible. 
-  - We want to write the majority of code in C#. 
+- Keep them as "thin"/1:1 as possible.
+  - We want to write the majority of code in C#.
 - Never skip the shim and P/Invoke directly to the underlying platform API. It's easy to assume something is safe/guaranteed when it isn't.
-- Don't cheat and take advantage of coincidental agreement between one flavor's ABI and the shim's ABI. 
+- Don't cheat and take advantage of coincidental agreement between one flavor's ABI and the shim's ABI.
 - Use PascalCase in a style closer to Win32 than libc.
   - If an export point has a 1:1 correspondence to the platform API, then name it after the platform API in PascalCase (e.g. stat -> Stat, fstat -> FStat).
   - If an export is not 1:1, then spell things out as we typically would in dotnet/runtime code (i.e. don't use abbreviations unless they come from the underlying API.

docs/design/coreclr/botr/corelib.md

@@ -201,7 +201,7 @@ Here's a real-world example from the `String` class:
 
 ```CSharp
 public partial sealed class String
-{        
+{
     [MethodImpl(MethodImplOptions.InternalCall)]
     private extern string? IsInterned();
 

docs/design/coreclr/botr/method-descriptor.md

@@ -1,4 +1,4 @@
-Method Descriptor
+Method Descriptor
 =================
 
 Author: Jan Kotas ([@jkotas](https://github.com/jkotas)) - 2006

docs/design/coreclr/botr/readytorun-format.md

@@ -9,7 +9,7 @@ Revisions:
 # Introduction
 
 This document describes ReadyToRun format 3.1 implemented in CoreCLR as of June 2019 and not yet
-implemented proposed extensions 4.1 for the support of composite R2R file format. 
+implemented proposed extensions 4.1 for the support of composite R2R file format.
 **Composite R2R file format** has basically the same structure as the traditional R2R file format
 defined in earlier revisions except that the output file represents a larger number of input MSIL
 assemblies compiled together as a logical unit.
@@ -320,8 +320,8 @@ basic encoding, with extended encoding for large values).
 
 ## ReadyToRunSectionType.RuntimeFunctions
 
-This section contains sorted array of `RUNTIME_FUNCTION` entries that describe all code blocks in the image with pointers to their unwind info. 
-Despite the name, these code block might represent a method body, or it could be just a part of it (e.g. a funclet) that requires its own unwind data. 
+This section contains sorted array of `RUNTIME_FUNCTION` entries that describe all code blocks in the image with pointers to their unwind info.
+Despite the name, these code block might represent a method body, or it could be just a part of it (e.g. a funclet) that requires its own unwind data.
 The standard Windows xdata/pdata format is used.
 ARM format is used for x86 to compensate for the lack of x86 unwind info standard.
 The unwind info blob is immediately followed by the GC info blob. The encoding slightly differs for amd64

docs/design/coreclr/botr/shared-generics.md

@@ -47,7 +47,7 @@ This feature is currently only supported for instantiations over reference types
 
 The dictionary used by any given generic method is pointed at by the `m_pPerInstInfo` field on the `InstantiatedMethodDesc` structure of that method. It's a direct pointer to the contents of the generic dictionary data.
 
-On generic types, there's an extra level of indirection: the `m_pPerInstInfo` field on the `MethodTable` structure is a pointer to a table of dictionaries, and each entry in that table is a pointer to the actual generic dictionary data. This is because types have inheritance, and derived generic types inherit the dictionaries of their base types. 
+On generic types, there's an extra level of indirection: the `m_pPerInstInfo` field on the `MethodTable` structure is a pointer to a table of dictionaries, and each entry in that table is a pointer to the actual generic dictionary data. This is because types have inheritance, and derived generic types inherit the dictionaries of their base types.
 
 Here's an example:
 ```c#

docs/design/coreclr/botr/type-system.md

@@ -1,4 +1,4 @@
-Type System Overview
+Type System Overview
 ====================
 
 Author: David Wrighton ([@davidwrighton](https://github.com/davidwrighton)) - 2010