fixes

src/libraries/System.Diagnostics.EventLog/src/Messages/readme.md

@@ -4,11 +4,11 @@ For more information see https://docs.microsoft.com/en-us/windows/win32/eventlog
 
 The design of the EventLog class is to allow for the registration of event sources without specifying message files.
 
-In the case an event source does not specify it's own message file, EventLog just provides a default message file 
+In the case an event source does not specify it's own message file, EventLog just provides a default message file
 with 64K message IDs all that just pass through the first insertion string.  This allow the event source to still
 use IDs for messages, but doesn't require the caller to actually pass a message file in order to achieve this.
 
-The process for producing the message file requires mc.exe and rc.exe which do not work cross-platform, and they 
+The process for producing the message file requires mc.exe and rc.exe which do not work cross-platform, and they
 require a VS install with C++ tools.  Since these files rarely (if ever) change, we just use a manual process for
 updating this res file.
 

src/libraries/System.Memory.Data/README.md

@@ -2,21 +2,21 @@
 
 ## Binary Data
  The `BinaryData` type provides a lightweight abstraction for a payload of bytes. It provides convenient helper methods to get out commonly used primitives, such as streams, strings, or bytes. The assumption when converting to and from string is that the encoding is UTF-8.
- 
+
  ### Data ownership
  When using the `byte[]` or `ReadOnlyMemory<byte>` constructors or methods, `BinaryData` will wrap the passed in bytes. When using streams, strings, or rich model types that will be serialized as Json, the data is converted into bytes and will be maintained by `BinaryData`. Thus, if you are using bytes to create your instance of `BinaryData`, changes to the underlying data will be reflected in `BinaryData` as it does not copy the bytes.
 
  ### Usage
  The main value of this type is its ability to easily convert from string to bytes to stream. This can greatly simplify API surface areas by exposing this type as opposed to numerous overloads or properties.
- 
+
 To/From string:
 ```C# Snippet:BinaryDataToFromString
 var data = new BinaryData("some data");
 
 // ToString will decode the bytes using UTF-8
 Console.WriteLine(data.ToString()); // prints "some data"
 ```
- 
+
  To/From bytes:
 ```C# Snippet:BinaryDataToFromBytes
 byte[] bytes = Encoding.UTF8.GetBytes("some data");

src/libraries/System.Text.Json/docs/KeyConverter_spec.md

@@ -7,7 +7,7 @@ Most of our users that serialize dictionary use `Dictionary<string, TKey>`; howe
 * 80%+ of dictionaries with non-string keys work out of the box, especially if they can round-trip.
 * Remain high performance.
 
-# Non-goals 
+# Non-goals
 * Complete parity with `Newtonsoft.Json` capabilities, especially in how string support is extended; any extension point can be through `JsonConverter<MyDictionary<non-string, TValue>>`.
 
 # Sample
@@ -24,7 +24,7 @@ string json = JsonSerializer.Serialize(root);
 
 Dictionary<int, string> rootCopy = JsonSerializer.Deserialize<Dictionary<int, string>>(json);
 Console.WriteLine(rootCopy[1]);
- // Prints 
+ // Prints
  // value
 ```
 
@@ -129,7 +129,7 @@ The custom `KeyConverter` that calls Utf8Parser underneath performs slightly fas
 
 # Prior-art
 ## Newtonsoft.Json
- 
+
 ### On write:
 
 * if the `TKey` is a concrete primitive type*:
@@ -140,16 +140,16 @@ The custom `KeyConverter` that calls Utf8Parser underneath performs slightly fas
     * Double (uses `double.ToString("R")`) // 'R' stands for round-trip
     * Single
     * Enum (uses an internal helper method)
- 
+
 * If the `TKey` is `object` or non-primitive.
   * it calls the `TypeConverter` of the `TKey` runtime type.
   Except for :
     * `Type`, which returns the `AssemblyQualifiedName`.
   * If the type does not have a `TypeConverter`, it calls `ToString()` on the `TKey` instance.
 
- 
-\* A *primitive type* is a value cataloged as such by Json.Net from [this list](https://github.com/JamesNK/Newtonsoft.Json/blob/a31156e90a14038872f54eb60ff0e9676ca4a0d8/Src/Newtonsoft.Json/Utilities/ConvertUtils.cs#L119-L168). 
-  
+
+\* A *primitive type* is a value cataloged as such by Json.Net from [this list](https://github.com/JamesNK/Newtonsoft.Json/blob/a31156e90a14038872f54eb60ff0e9676ca4a0d8/Src/Newtonsoft.Json/Utilities/ConvertUtils.cs#L119-L168).
+
 ### On read:
 
 * If the `TKey` is a concrete type.
@@ -181,5 +181,5 @@ Supported types:
 1. `DictionaryKeyPolicy` will apply to the resulting string of the non-string types.
 1. Should we provide a way to allow users to customize the `EnumKeyConverter` behavior, as it is done in `JsonStringEnumConverter`?
 As of now `KeyConverter`s are meant to be internal types, to enable the previously described behavior we either pass the options through `JsonSerializerOptions` or through an attribute.
-1. Discuss support for `object` as the `TKey` type on deserialization, should we support it in this enhancement? `object` is treated as a `JsonElement` on deserialization and is not part of the supported types on the `Utf8Parser/Formatter`. 
+1. Discuss support for `object` as the `TKey` type on deserialization, should we support it in this enhancement? `object` is treated as a `JsonElement` on deserialization and is not part of the supported types on the `Utf8Parser/Formatter`.
 Consider to defer it when we add support for intuitive types (parse keys as string, etc. instead of JsonElement).

src/mono/sample/wasm/browser-profile/README.md

@@ -15,7 +15,7 @@
 var Module = {
   onRuntimeInitialized: function () {
     ...
-    
+
     if (config.enable_profiler)
     {
       config.aot_profiler_options = {
@@ -52,17 +52,17 @@ function saveProfile() {
 1. To enable profiling during a build, we need to make use of WasmApp.InTree.targets/props by importing into the project file:
 
 `<Import Project="$(MonoProjectRoot)\wasm\build\WasmApp.InTree.targets" />` <br/>
-`<Import Project="$(MonoProjectRoot)wasm\build\WasmApp.InTree.props" />` 
+`<Import Project="$(MonoProjectRoot)wasm\build\WasmApp.InTree.props" />`
 
 For more information on how to utilize WasmApp.InTree.targets/props consult the wasm build directory [README.md](../../../../wasm/build/README.md)
 
-2. To get the profile data, run: 
+2. To get the profile data, run:
 
 `make get-aot-profile`
 
 Which will build and run the current project with AOT disabled and the AOT profiler enabled.
 
-3. Go to localhost:8000 and the profile will automatically download. 
+3. Go to localhost:8000 and the profile will automatically download.
 
 4. To use the profile data in the project, run:
 

src/mono/wasm/build/README.md

@@ -18,7 +18,7 @@ the specified `@(WasmAssembliesToBundle)` are directly passed to
 	set `$(WasmResolveAssembliesBeforeBuild) == true`.
   - Should you need to run the AOT toolset, ensure `$(RunAOTCompilation) == true`
   and set `$(WasmAOTDir)` to the directory that you want to AOT. Make sure that both
-  `@(WasmAssembliesToBundle)` and `$(WasmAOTDir)` are absolute paths. 
+  `@(WasmAssembliesToBundle)` and `$(WasmAOTDir)` are absolute paths.
 
 - Assemblies to be bundled with the app are set via
 `@(WasmAssembliesToBundle)` (which optionally will have dependencies

src/tests/FunctionalTests/README.md

@@ -1,7 +1,7 @@
 # Functional tests
 
-This directory contains the functional tests for the supported platforms.  
+This directory contains the functional tests for the supported platforms.
 
-Currently the functional tests build is incorporated into the library tests build.  
+Currently the functional tests build is incorporated into the library tests build.
 
-The functional tests run in CI.  
+The functional tests run in CI.