Remove references to gender (dotnet#262)

Author: drewnoakes

docs/coding-guidelines/clr-code-guide.md

@@ -975,7 +975,7 @@ In typical managed app scenarios, services like WszCreateEvent are thin wrappers
 
 If you need to coordinate with unmanaged code, or if you need to do WaitForMultipleHandles ANY/ALL, you will have to avoid WszCreateEvent. If you really know what you are doing, go directly to the OS to obtain these handles. Everyone else should seek advice from someone who thoroughly understands the implications to our host. Obviously the general rule is that everyone should go through our hosted abstraction.
 
-Sometimes you might find yourself building the equivalent of a critical section, but using an event directly. The problem here is that we cannot identify the thread that owns the lock, because the owner isn't identified until he "leaves'" the lock by calling SetEvent or Pulse. Consider whether a Crst might be more appropriate.
+Sometimes you might find yourself building the equivalent of a critical section, but using an event directly. The problem here is that we cannot identify the thread that owns the lock, because the owner isn't identified until they "leave'" the lock by calling SetEvent or Pulse. Consider whether a Crst might be more appropriate.
 
 ### <a name="2.6.12"/>2.6.12 Do not get clever with "lockless" reader-writer data structures
 

docs/design/coreclr/botr/botr-faq.md

@@ -29,7 +29,7 @@ A design doc is what you write before you start implementation. A BotR chapter i
 
 A new dev can be a great contributor to BotR as one of the most important purposes of BotR is to help new devs with getting up to speed. Here are some ways you can contribute:
 
-- Be a reviewer! If you think some things are not clear or could be explained better, do not hesitate to contact the author of the chapter and chat with him/her to see how you can make it more understandable.
+- Be a reviewer! If you think some things are not clear or could be explained better, do not hesitate to contact the author of the chapter and chat with them to see how you can make it more understandable.
 - As you are getting up to speed in your area, look over the BotR chapters for your area and see if there are any errors or anything that requires an update and make the modifications yourself.
 - Volunteer to write a chapter or part of a chapter. This might seem like a daunting task but you can start by just accumulating knowledge - take notes as you learn stuff about your area and gradually mold it into a BotR chapter.
 

docs/design/coreclr/botr/intro-to-clr.md

@@ -204,7 +204,7 @@ As an aside, while exceptions avoid one common error (not checking for failure),
 
 Previous to version 2.0 of the CLR, the only parameterized types were arrays.  All other containers (such as hash tables, lists, queues, etc.), all operated on a generic Object type.  The inability to create List<ElemT>, or Dictionary<KeyT, ValueT> certainly had a negative performance effect because value types needed to be boxed on entry to a collection, and explicit casting was needed on element fetch.  Nevertheless, that is not the overriding reason for adding parameterized types to the CLR.  The main reason is that **parameterized types make programming easier**.
 
-The reason for this is subtle.  The easiest way to see the effect is to imagine what a class library would look like if all types were replaced with a generic Object type.  This effect is not unlike what happens in dynamically typed languages like JavaScript.  In such a world, there are simply far more ways for a programmer to make incorrect (but type-safe) programs.  Is the parameter for that method supposed to be a list? a string? an integer? any of the above? It is no longer obvious from looking at the method's signature.  Worse, when a method returns an Object, what other methods can accept it as a parameter? Typical frameworks have hundreds of methods; if they all take parameters of type Object, it becomes very difficult to determine which Object instances are valid for the operations the method will perform.  In short, strong typing helps a programmer express his intent more clearly, and allows tools (e.g., the compiler) to enforce his intent.  This results in big productivity boost.
+The reason for this is subtle.  The easiest way to see the effect is to imagine what a class library would look like if all types were replaced with a generic Object type.  This effect is not unlike what happens in dynamically typed languages like JavaScript.  In such a world, there are simply far more ways for a programmer to make incorrect (but type-safe) programs.  Is the parameter for that method supposed to be a list? a string? an integer? any of the above? It is no longer obvious from looking at the method's signature.  Worse, when a method returns an Object, what other methods can accept it as a parameter? Typical frameworks have hundreds of methods; if they all take parameters of type Object, it becomes very difficult to determine which Object instances are valid for the operations the method will perform.  In short, strong typing helps a programmer express their intent more clearly, and allows tools (e.g., the compiler) to enforce their intent.  This results in big productivity boost.
 
 These benefits do not disappear just because the type gets put into a List or a Dictionary, so clearly parameterized types have value.  The only real question is whether parameterized types are best thought of as a language specific feature which is "compiled out" by the time CIL is generated, or whether this feature should have first class support in the runtime.  Either implementation is certainly possible.  The CLR team chose first class support because without it, parameterized types would be implemented different ways by different languages.  This would imply that interoperability would be cumbersome at best.  In addition, expressing programmer intent for parameterized types is most valuable _at the interface_ of a class library.  If the CLR did not officially support parameterized types, then class libraries could not use them, and an important usability feature would be lost.
 

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

@@ -257,7 +257,7 @@ These conventions would be codified as well.
 
 Because it was already the case that methods outside the current module had to use an indirect call, versionability does not introduce more overhead for non-virtual method calls if inlining was not done. Thus the main cost of  making the native code version resilient is the requirement that no cross version bubble inlining can happen.
 
-The best solution to this problem is to avoid 'chatty' library designs (Unfortunately, `IEnumerable`, is such a chatty design, where each iteration does a `MoveNext` and `Current` property fetch). Another mitigation is the one mentioned previously: to allow clients of the library to selectively JIT compile some methods that make these chatty calls. Finally you can also use new custom `NonVersionableAttribute` attribute, which effectively changes the versioning contract to indicate that the library supplier has given up his right to change that method's body and thus it would be legal to inline.
+The best solution to this problem is to avoid 'chatty' library designs (Unfortunately, `IEnumerable`, is such a chatty design, where each iteration does a `MoveNext` and `Current` property fetch). Another mitigation is the one mentioned previously: to allow clients of the library to selectively JIT compile some methods that make these chatty calls. Finally you can also use new custom `NonVersionableAttribute` attribute, which effectively changes the versioning contract to indicate that the library supplier has given up their right to change that method's body and thus it would be legal to inline.
 
 The proposal is to disallow cross-version bubble inlining by default, and selectively allow inlining for critical methods (by giving up the right to change the method).
 

docs/project/api-review-process.md

@@ -23,10 +23,10 @@ isn't necessarily to perform an in-depth review; rather, we want to make sure
 that the proposal is actionable, i.e. has a concrete design, a sketch of the
 APIs and some code samples that show how it should be used. If changes are necessary, the requester is encouraged to edit the issue description. This allows folks joining later to understand the most recent proposal. To avoid confusion, the requester should maintain a tiny change log, like a bolded "Updates:" followed by a bullet point list of the updates that were being made.
 
-4. **Owner makes decision**. When the owner believes enough information is available to make a decision, she will update the issue accordingly:
+4. **Owner makes decision**. When the owner believes enough information is available to make a decision, they will update the issue accordingly:
 
-    * **Mark for review**. If the owner believes the proposal is actionable, she will label the issue with `api-ready-for-review`. Here is [a good example](https://github.com/dotnet/corefx/issues/4547) of as strong API proposal.
-    * **Close as not actionable**. In case the issue didn't get enough traction to be distilled into a concrete proposal, she will close the issue.
+    * **Mark for review**. If the owner believes the proposal is actionable, they will label the issue with `api-ready-for-review`. Here is [a good example](https://github.com/dotnet/corefx/issues/4547) of as strong API proposal.
+    * **Close as not actionable**. In case the issue didn't get enough traction to be distilled into a concrete proposal, the owner will close the issue.
     * **Close as won't fix as proposed**. Sometimes, the issue that is raised is a good one but the owner thinks the concrete proposal is not the right way to tackle the problem. In most cases, the owner will try to steer the discussion in a direction that results in a design that we believe is appropriate. However, for some proposals the problem is at the heart of the design which can't easily be changed without starting a new proposal. In those cases, the owner will close the issue and explain the issue the design has.
     * **Close as won't fix**. Similarly, if proposal is taking the product in a direction we simply don't want to go, the issue might also get closed. In that case, the problem isn't the proposed design but in the issue itself.
 

docs/project/writing-tests.md

@@ -59,7 +59,7 @@ public async Task Headers_SetAfterRequestSubmitted_ThrowsInvalidOperationExcepti
 This one is fairly simple but often used incorrectly. When running tests which depend on outside influences like e.g. Hardware (Internet, SerialPort, ...) and you can't mitigate these dependencies, you might consider using the `[OuterLoop]` attribute for your test. 
 With this attribute, tests are executed in a dedicated CI loop and won't break the default CI loops which get created when you submit a PR.
 To run OuterLoop tests locally you need to set the msbuild property "OuterLoop" to true: `/p:OuterLoop=true`.
-To run OuterLoop tests in CI you need to mention dotnet-bot and tell him which tests you want to run. See `@dotnet-bot help` for the exact loop names.
+To run OuterLoop tests in CI you need to mention dotnet-bot and identify the tests you want to run. See `@dotnet-bot help` for the exact loop names.
 
 This doesn't mean that you should mark every test which executes against a remote endpoint as OuterLoop. See below.
 

src/coreclr/src/System.Private.CoreLib/src/System/Diagnostics/Debugger.cs

@@ -12,7 +12,7 @@ namespace System.Diagnostics
     public static class Debugger
     {
         // Break causes a breakpoint to be signalled to an attached debugger.  If no debugger
-        // is attached, the user is asked if he wants to attach a debugger. If yes, then the
+        // is attached, the user is asked if they want to attach a debugger. If yes, then the
         // debugger is launched.
         [MethodImpl(MethodImplOptions.NoInlining)]
         public static void Break() => BreakInternal();

src/coreclr/src/debug/daccess/nidump.cpp

@@ -4117,7 +4117,7 @@ void NativeImageDumper::IterateTypeRefToMTCallback( TADDR mtTarget,
     {
         RVA rva = CORCOMPILE_UNTAG_TOKEN(PTR_TO_TADDR(mt));
         //
-        // This guy writes two things FixupTargetValue and FixupTargetName
+        // This writes two things FixupTargetValue and FixupTargetName
         //
         WriteElementsFixupBlob( NULL,PTR_TO_TADDR(mt));
     }

src/coreclr/src/debug/di/rsstackwalk.cpp

@@ -741,8 +741,8 @@ HRESULT CordbStackWalk::GetFrameWorker(ICorDebugFrame ** ppFrame)
             _ASSERTE(pCode != NULL);
 
             // We populate the code for ReJit eagerly to make sure we still have it if the profiler removes the
-            // instrumentation later. Of course the only way it will still be accessible to our caller is if he
-            // saves a pointer to the ILCode.
+            // instrumentation later. Of course the only way it will still be accessible to our caller is if they
+            // save a pointer to the ILCode.
             // I'm not sure if ignoring rejit for mini-dumps is the right call long term, but we aren't doing
             // anything special to collect the memory at dump time so we better be prepared to not fetch it here.
             // We'll attempt to treat it as not being instrumented, though I suspect the abstraction is leaky.

src/coreclr/src/debug/di/rsthread.cpp

@@ -4020,7 +4020,7 @@ HRESULT CordbUnmanagedThread::SetupGenericHijack(DWORD eventCode, const EXCEPTIO
 
 #endif // DBG_TARGET_AMD64 || defined(DBG_TARGET_ARM64)
 
-    // Remember that we've hijacked the guy.
+    // Remember that we've hijacked the thread.
     SetState(CUTS_GenericHijacked);
 
     LOG((LF_CORDB, LL_INFO1000000, "CUT::SGH: Current IP is 0x%08x\n", CORDbgGetIP(GetHijackCtx())));