Remove references to gender (dotnet#262)

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())));

src/coreclr/src/debug/ee/controller.cpp

@@ -7557,7 +7557,7 @@ void DebuggerStepper::TriggerUnwind(Thread *thread,
 
 
 // Prepare for sending an event.
-// This is called 1:1 w/ SendEvent, but this guy can be called in a GC_TRIGGERABLE context
+// This is called 1:1 w/ SendEvent, but this method can be called in a GC_TRIGGERABLE context
 // whereas SendEvent is pretty strict.
 // Caller ensures that it's safe to run a stack trace.
 void DebuggerStepper::PrepareForSendEvent(StackTraceTicket ticket)

src/coreclr/src/debug/shared/dbgtransportsession.cpp

@@ -1339,7 +1339,7 @@ void DbgTransportSession::TransportWorker()
         }
 
         // Note that when resynching a session we may let in a connection from a different debugger. That's
-        // OK, we'll reject his SessionRequest message in due course and drop the connection.
+        // OK, we'll reject its SessionRequest message in due course and drop the connection.
 #endif // RIGHT_SIDE_COMPILE
 
         DBG_TRANSPORT_INC_STAT(Connections);

src/coreclr/src/ilasm/prebuilt/asmparse.cpp

@@ -1999,9 +1999,9 @@ YYLOCAL YYNEAR YYPASCAL YYPARSER()
 				**  we were supposed to get is the one when j > 0. for example,
 				**  for(+) {;} error recovery with yyerrflag always set, stops
 				**  after inserting one ; before the +. at the point of the +,
-				**  we're pretty sure the guy wants a 'for' loop. without
+				**  we're pretty sure the caller wants a 'for' loop. without
 				**  setting the flag, when we're almost absolutely sure, we'll
-				**  give him one, since the only thing we can shift on this
+				**  give them one, since the only thing we can shift on this
 				**  error is after finding an expression followed by a +
 				*/
 					yyerrflag++;

src/coreclr/src/ildasm/dasm.cpp

@@ -4949,7 +4949,7 @@ void DumpVTables(IMAGE_COR20_HEADER *CORHeader, void* GUICookie)
     sprintf_s(szString,SZSTRING_SIZE,"// VTableFixup Directory:");
     printLine(GUICookie,szStr);
 
-    // Pull back a pointer to the guy.
+    // Pull back a pointer to it.
     iCount = VAL32(CORHeader->VTableFixups.Size) / sizeof(IMAGE_COR_VTABLEFIXUP);
     if ((g_pPELoader->getVAforRVA(VAL32(CORHeader->VTableFixups.VirtualAddress), (void **) &pFixup) == FALSE)
         ||(g_pPELoader->getVAforRVA(VAL32(CORHeader->VTableFixups.VirtualAddress)+VAL32(CORHeader->VTableFixups.Size)-1, (void **) &pDummy) == FALSE))
@@ -5022,7 +5022,7 @@ void DumpEATTable(IMAGE_COR20_HEADER *CORHeader, void* GUICookie)
         return;
     }
 
-    // Pull back a pointer to the guy.
+    // Pull back a pointer to it.
     iCount = VAL32(CORHeader->ExportAddressTableJumps.Size) / IMAGE_COR_EATJ_THUNK_SIZE;
     if ((g_pPELoader->getVAforRVA(VAL32(CORHeader->ExportAddressTableJumps.VirtualAddress), (void **) &pFixup) == FALSE)
         ||(g_pPELoader->getVAforRVA(VAL32(CORHeader->ExportAddressTableJumps.VirtualAddress)+VAL32(CORHeader->ExportAddressTableJumps.Size)-1, (void **) &pDummy) == FALSE))

src/coreclr/src/inc/bitvector.h

@@ -51,7 +51,7 @@
 
            Specifically did NOT supply automatic coersions to
            and from short types so that the programmer is aware of
-           when code was being injected on his behalf.  The upshot of this
+           when code was being injected on their behalf.  The upshot of this
            is that you have to use the  BitVector() toUnsigned() to convert
 */
 

src/coreclr/src/inc/safewrap.h

@@ -157,7 +157,7 @@ DWORD inline SafeGetFileSize(HANDLE hFile, DWORD *pdwHigh)
             // note that a success return of (hi=0,lo=0xffffffff) will be
             // treated as an error by the caller. Again, that's part of the
             // price of being a slacker and not handling the high dword.
-            // We'll set a lasterror for him to pick up.
+            // We'll set a lasterror for them to pick up.
             SetLastError(ERROR_NOT_ENOUGH_MEMORY);
         }
 

src/coreclr/src/inc/stack.h

@@ -75,7 +75,7 @@ class Stack
         return m_elems[m_elemsCount-1];
     }
 
-    // Caller should take care to only side-effect the return reference if he/she is *sure*
+    // Caller should take care to only side-effect the return reference if they are *sure*
     // that the stack will not be popped in the interim!
     T& PeekRef()
     {

src/coreclr/src/jit/codegenxarch.cpp

@@ -392,7 +392,7 @@ BasicBlock* CodeGen::genCallFinally(BasicBlock* block)
     }
     else
     {
-        // EE expects a DWORD, so we give him 0
+        // EE expects a DWORD, so we provide 0
         inst_IV(INS_push_hide, 0);
     }
 

src/coreclr/src/jit/error.h

@@ -155,7 +155,7 @@ extern void RecordNowayAssertGlobal(const char* filename, unsigned line, const c
 
 #if defined(ALT_JIT)
 
-// This guy can return based on Config flag/Debugger
+// This can return based on Config flag/Debugger
 extern void notYetImplemented(const char* msg, const char* file, unsigned line);
 #define NYIRAW(msg) notYetImplemented(msg, __FILE__, __LINE__)
 

src/coreclr/src/md/compiler/disp.cpp

@@ -144,7 +144,7 @@ Disp::DefineScope(
     }
 #endif // ENC_DELTA_HACK
 
-    // Create a new coclass for this guy.
+    // Create a new coclass for this.
     pMeta = new (nothrow) RegMeta();
     IfNullGo(pMeta);
 

src/coreclr/src/md/enc/metamodelrw.cpp

@@ -5882,7 +5882,7 @@ CMiniMdRW::FixParamSequence(
     // Param table should not be empty at this point.
     _ASSERTE(ixEnd > ixStart);
 
-    // Get a pointer to the new guy.
+    // Get a pointer to the new parameter.
     RID ridNew;
     ParamPtrRec * pNewParamPtr = NULL;
     if (HasIndirectTable(TBL_Param))
@@ -5930,7 +5930,7 @@ CMiniMdRW::FixParamSequence(
     }
 
     // If the item is out of order, move everything down one slot and
-    // copy the new guy into the new location.  Because the heap can be
+    // copy the new parameter into the new location.  Because the heap can be
     // split, this must be done carefully.
     //<TODO>@Future: one could write a more complicated but faster routine that
     // copies blocks within heaps.</TODO>

src/coreclr/src/md/inc/metamodelrw.h

@@ -596,7 +596,7 @@ class CMiniMdRW : public CMiniMdTemplate<CMiniMdRW>
     // Add a new MemberRef to the hash table.
     __checkReturn
     HRESULT AddMemberRefToHash(             // Return code.
-        mdMemberRef mr);                    // Token of new guy.
+        mdMemberRef mr);                    // Token of new MemberRef.
 
     // If the hash is built, search for the item. Ignore token *ptkMemberRef.
     HashSearchResult FindMemberRefFromHash(
@@ -620,7 +620,7 @@ class CMiniMdRW : public CMiniMdTemplate<CMiniMdRW>
     // Add a new MemberDef to the hash table.
     __checkReturn
     HRESULT AddMemberDefToHash(
-        mdToken tkMember,   // Token of new guy. It can be MethodDef or FieldDef
+        mdToken tkMember,   // Token of new def. It can be MethodDef or FieldDef
         mdToken tkParent);  // Parent token.
 
     // Create MemberDef Hash