From 7f8be3eb3440a152246a1aef7b4020be4c03cf2e Mon Sep 17 00:00:00 2001 From: Richard Eisenberg Date: Wed, 28 Oct 2020 17:51:42 -0400 Subject: Remove unnecessary gender from comments/docs 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. --- compiler/GHC/Core/Opt/Pipeline.hs | 2 +- compiler/GHC/Core/Opt/SpecConstr.hs | 4 ++-- compiler/GHC/Core/TyCon.hs | 4 ++-- compiler/GHC/Core/Utils.hs | 3 +-- compiler/GHC/HsToCore/Pmc/Solver/Types.hs | 2 +- compiler/GHC/HsToCore/Utils.hs | 2 +- compiler/GHC/Parser/PostProcess.hs | 4 ++-- compiler/GHC/Runtime/Interpreter.hs | 2 +- compiler/GHC/Tc/Gen/Expr.hs | 2 +- compiler/GHC/Tc/Gen/Splice.hs | 2 +- compiler/GHC/Tc/Solver/Interact.hs | 4 ++-- compiler/GHC/Tc/TyCl.hs | 2 +- compiler/GHC/Types/Basic.hs | 2 +- compiler/GHC/Types/Name/Reader.hs | 2 +- compiler/GHC/Utils/Outputable.hs | 4 ++-- docs/users_guide/exts/partial_type_signatures.rst | 2 +- 16 files changed, 21 insertions(+), 22 deletions(-) diff --git a/compiler/GHC/Core/Opt/Pipeline.hs b/compiler/GHC/Core/Opt/Pipeline.hs index 041fdf3a29..c8e10865cb 100644 --- a/compiler/GHC/Core/Opt/Pipeline.hs +++ b/compiler/GHC/Core/Opt/Pipeline.hs @@ -895,7 +895,7 @@ Old "solution": of iterateList in the first place But in principle the user *might* want rules that only apply to the Id -he says. And inline pragmas are similar +they say. And inline pragmas are similar {-# NOINLINE f #-} f = local local = diff --git a/compiler/GHC/Core/Opt/SpecConstr.hs b/compiler/GHC/Core/Opt/SpecConstr.hs index d3ee317234..2ca8e1a080 100644 --- a/compiler/GHC/Core/Opt/SpecConstr.hs +++ b/compiler/GHC/Core/Opt/SpecConstr.hs @@ -1744,8 +1744,8 @@ Note [spec_usg includes rhs_usg] In calls to 'specialise', the returned ScUsage must include the rhs_usg in the passed-in SpecInfo, unless there are no calls at all to the function. -The caller can, indeed must, assume this. He should not combine in rhs_usg -himself, or he'll get rhs_usg twice -- and that can lead to an exponential +The caller can, indeed must, assume this. They should not combine in rhs_usg +themselves, or they'll get rhs_usg twice -- and that can lead to an exponential blowup of duplicates in the CallEnv. This is what gave rise to the massive performance loss in #8852. diff --git a/compiler/GHC/Core/TyCon.hs b/compiler/GHC/Core/TyCon.hs index ad455779b7..9982436429 100644 --- a/compiler/GHC/Core/TyCon.hs +++ b/compiler/GHC/Core/TyCon.hs @@ -224,8 +224,8 @@ See also Note [Wrappers for data instance tycons] in GHC.Types.Id.Make * Reply "yes" to isDataFamilyTyCon, and isFamilyTyCon -* The user does not see any "equivalent types" as he did with type - synonym families. He just sees constructors with types +* The user does not see any "equivalent types" as they did with type + synonym families. They just see constructors with types T1 :: T Int T2 :: Bool -> T Int diff --git a/compiler/GHC/Core/Utils.hs b/compiler/GHC/Core/Utils.hs index 076d5213d9..e980c560e0 100644 --- a/compiler/GHC/Core/Utils.hs +++ b/compiler/GHC/Core/Utils.hs @@ -1511,7 +1511,7 @@ Note [Expandable overloadings] Suppose the user wrote this {-# RULE forall x. foo (negate x) = h x #-} f x = ....(foo (negate x)).... -He'd expect the rule to fire. But since negate is overloaded, we might +They'd expect the rule to fire. But since negate is overloaded, we might get this: f = \d -> let n = negate d in \x -> ...foo (n x)... So we treat the application of a function (negate in this case) to a @@ -2621,4 +2621,3 @@ isUnsafeEqualityProof e = idName v == unsafeEqualityProofName | otherwise = False - diff --git a/compiler/GHC/HsToCore/Pmc/Solver/Types.hs b/compiler/GHC/HsToCore/Pmc/Solver/Types.hs index 7afb26fcc6..3ff4b4cbb2 100644 --- a/compiler/GHC/HsToCore/Pmc/Solver/Types.hs +++ b/compiler/GHC/HsToCore/Pmc/Solver/Types.hs @@ -90,7 +90,7 @@ initNabla = MkNabla initTyState initTmState instance Outputable Nabla where ppr nabla = hang (text "Nabla") 2 $ vcat [ -- intentionally formatted this way enable the dev to comment in only - -- the info she needs + -- the info they need ppr (nabla_tm_st nabla), ppr (nabla_ty_st nabla) ] diff --git a/compiler/GHC/HsToCore/Utils.hs b/compiler/GHC/HsToCore/Utils.hs index 0e685cc69d..01085b3270 100644 --- a/compiler/GHC/HsToCore/Utils.hs +++ b/compiler/GHC/HsToCore/Utils.hs @@ -454,7 +454,7 @@ There are a few subtleties in the desugaring of `seq`: I# _ -> ...case b of {True -> fst x; False -> 0}... We can try to avoid doing this by ensuring that the binder-swap in the - case happens, so we get his at an early stage: + case happens, so we get this at an early stage: case chp of chp2 { I# -> ...chp2... } But this is fragile. The real culprit is the source program. Perhaps we should have said explicitly diff --git a/compiler/GHC/Parser/PostProcess.hs b/compiler/GHC/Parser/PostProcess.hs index 31e861a215..20a8f179d1 100644 --- a/compiler/GHC/Parser/PostProcess.hs +++ b/compiler/GHC/Parser/PostProcess.hs @@ -338,8 +338,8 @@ mkSpliceDecl :: LHsExpr GhcPs -> HsDecl GhcPs -- If the user wrote -- [pads| ... ] then return a QuasiQuoteD -- $(e) then return a SpliceD --- but if she wrote, say, --- f x then behave as if she'd written $(f x) +-- but if they wrote, say, +-- f x then behave as if they'd written $(f x) -- ie a SpliceD -- -- Typed splices are not allowed at the top level, thus we do not represent them diff --git a/compiler/GHC/Runtime/Interpreter.hs b/compiler/GHC/Runtime/Interpreter.hs index b2df09f35f..6cd00efdd2 100644 --- a/compiler/GHC/Runtime/Interpreter.hs +++ b/compiler/GHC/Runtime/Interpreter.hs @@ -411,7 +411,7 @@ handleSeqHValueStatus :: HscEnv -> EvalStatus () -> IO (EvalResult ()) handleSeqHValueStatus hsc_env eval_status = do case eval_status of (EvalBreak is_exception _ ix mod_uniq resume_ctxt _) -> do - -- A breakpoint was hit, inform the user and tell him + -- A breakpoint was hit; inform the user and tell them -- which breakpoint was hit. resume_ctxt_fhv <- liftIO $ mkFinalizedHValue hsc_env resume_ctxt let hmi = expectJust "handleRunStatus" $ diff --git a/compiler/GHC/Tc/Gen/Expr.hs b/compiler/GHC/Tc/Gen/Expr.hs index 5d919280f0..298ea5b138 100644 --- a/compiler/GHC/Tc/Gen/Expr.hs +++ b/compiler/GHC/Tc/Gen/Expr.hs @@ -103,7 +103,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 c9c134dfbe..98050b275b 100644 --- a/compiler/GHC/Tc/Gen/Splice.hs +++ b/compiler/GHC/Tc/Gen/Splice.hs @@ -565,7 +565,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 971a4442a5..da07c4a01f 100644 --- a/compiler/GHC/Tc/TyCl.hs +++ b/compiler/GHC/Tc/TyCl.hs @@ -953,7 +953,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: diff --git a/compiler/GHC/Types/Basic.hs b/compiler/GHC/Types/Basic.hs index e4705fdc9a..0f6f728da6 100644 --- a/compiler/GHC/Types/Basic.hs +++ b/compiler/GHC/Types/Basic.hs @@ -1352,7 +1352,7 @@ If you want to know where InlinePragmas take effect: Look in GHC.HsToCore.Binds. Note [inl_inline and inl_act] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* inl_inline says what the user wrote: did she say INLINE, NOINLINE, +* inl_inline says what the user wrote: did they say INLINE, NOINLINE, INLINABLE, or nothing at all * inl_act says in what phases the unfolding is active or inactive diff --git a/compiler/GHC/Types/Name/Reader.hs b/compiler/GHC/Types/Name/Reader.hs index 733a5472b8..d1a071dd93 100644 --- a/compiler/GHC/Types/Name/Reader.hs +++ b/compiler/GHC/Types/Name/Reader.hs @@ -1345,7 +1345,7 @@ pprLoc (UnhelpfulSpan {}) = empty -- (b) it is always in scope -- (c) it is a synonym for Data.Kind.Type -- --- However, the user might not know that he's working on a module with +-- However, the user might not know that they are working on a module with -- NoStarIsType and write code that still assumes (a), (b), and (c), which -- actually do not hold in that module. -- diff --git a/compiler/GHC/Utils/Outputable.hs b/compiler/GHC/Utils/Outputable.hs index 489c20cd75..16e66ce6d1 100644 --- a/compiler/GHC/Utils/Outputable.hs +++ b/compiler/GHC/Utils/Outputable.hs @@ -1287,8 +1287,8 @@ speakNth n = hcat [ int n, text suffix ] -- > speakN 5 = text "five" -- > speakN 10 = text "10" speakN :: Int -> SDoc -speakN 0 = text "none" -- E.g. "he has none" -speakN 1 = text "one" -- E.g. "he has one" +speakN 0 = text "none" -- E.g. "they have none" +speakN 1 = text "one" -- E.g. "they have one" speakN 2 = text "two" speakN 3 = text "three" speakN 4 = text "four" diff --git a/docs/users_guide/exts/partial_type_signatures.rst b/docs/users_guide/exts/partial_type_signatures.rst index 20689d9129..4d523dd80f 100644 --- a/docs/users_guide/exts/partial_type_signatures.rst +++ b/docs/users_guide/exts/partial_type_signatures.rst @@ -224,7 +224,7 @@ extra-constraints wildcard is used to infer three extra constraints. arbitCs :: _ => a -> String An extra-constraints wildcard shouldn't prevent the programmer from -already listing the constraints he knows or wants to annotate, e.g. +already listing the constraints they know or want to annotate, e.g. :: -- cgit v1.2.1