Remove unnecessary gender from comments/docswip/neuter

While, say, alternating "he" and "she" in sequential writing
may be nicer than always using "they", reading code/documentation
is almost never sequential. If this small change makes individuals
feel more welcome in GHC's codebase, that's a good thing.

4 files changed, 5 insertions, 5 deletions

diff --git a/compiler/GHC/Tc/Gen/Expr.hs b/compiler/GHC/Tc/Gen/Expr.hs
index a64154facf..cf0f2a59ef 100644
--- a/compiler/GHC/Tc/Gen/Expr.hs
+++ b/compiler/GHC/Tc/Gen/Expr.hs
@@ -101,7 +101,7 @@ tcCheckPolyExpr, tcCheckPolyExprNC
 -- tcCheckPolyExpr is a convenient place (frequent but not too frequent)
 -- place to add context information.
 -- The NC version does not do so, usually because the caller wants
--- to do so himself.
+-- to do so themselves.
 
 tcCheckPolyExpr   expr res_ty = tcPolyExpr   expr (mkCheckExpType res_ty)
 tcCheckPolyExprNC expr res_ty = tcPolyExprNC expr (mkCheckExpType res_ty)
diff --git a/compiler/GHC/Tc/Gen/Splice.hs b/compiler/GHC/Tc/Gen/Splice.hs
index c83890b1ae..c925ce3791 100644
--- a/compiler/GHC/Tc/Gen/Splice.hs
+++ b/compiler/GHC/Tc/Gen/Splice.hs
@@ -553,7 +553,7 @@ We only produce warnings for TH splices when the user requests so
 (-fenable-th-splice-warnings). There are multiple reasons:
 
   * It's not clear that the user that compiles a splice is the author of the code
-    that produces the warning. Think of the situation where she just splices in
+    that produces the warning. Think of the situation where they just splice in
     code from a third-party library that produces incomplete pattern matches.
     In this scenario, the user isn't even able to fix that warning.
   * Gathering information for producing the warnings (pattern-match check
diff --git a/compiler/GHC/Tc/Solver/Interact.hs b/compiler/GHC/Tc/Solver/Interact.hs
index fe349866d2..ad276aa5d2 100644
--- a/compiler/GHC/Tc/Solver/Interact.hs
+++ b/compiler/GHC/Tc/Solver/Interact.hs
@@ -88,7 +88,7 @@ Note [Basic Simplifier Plan]
       - If (ContinueWith ct) is returned by a stage, we feed 'ct' on to
         the next stage in the pipeline.
 4. If the element has survived (i.e. ContinueWith x) the last stage
-   then we add him in the inerts and jump back to Step 1.
+   then we add it in the inerts and jump back to Step 1.
 
 If in Step 1 no such element exists, we have exceeded our context-stack
 depth and will simply fail.
@@ -1671,7 +1671,7 @@ variable *on the left* of the equality. Here is what happens if not:
   Original wanted:  (a ~ alpha),  (alpha ~ Int)
 We spontaneously solve the first wanted, without changing the order!
       given : a ~ alpha      [having unified alpha := a]
-Now the second wanted comes along, but he cannot rewrite the given, so we simply continue.
+Now the second wanted comes along, but it cannot rewrite the given, so we simply continue.
 At the end we spontaneously solve that guy, *reunifying*  [alpha := Int]
 
 We avoid this problem by orienting the resulting given so that the unification
diff --git a/compiler/GHC/Tc/TyCl.hs b/compiler/GHC/Tc/TyCl.hs
index bd47bf7bd9..06684d4ed5 100644
--- a/compiler/GHC/Tc/TyCl.hs
+++ b/compiler/GHC/Tc/TyCl.hs
@@ -942,7 +942,7 @@ The question for this Note is this:
 Much of the debate is memorialized in #15743.
 
 Here is our design choice. When inferring the ordering of variables
-for a TyCl declaration (that is, for those variables that he user
+for a TyCl declaration (that is, for those variables that the user
 has not specified the order with an explicit `forall`), we use the
 following order: