[Git][ghc/ghc][master] Remove unnecessary gender from comments/docs
Marge Bot
gitlab at gitlab.haskell.org
Fri Oct 30 02:08:27 UTC 2020
Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC
Commits:
7f8be3eb by Richard Eisenberg at 2020-10-29T22:08:13-04:00
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.
- - - - -
16 changed files:
- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/HsToCore/Pmc/Solver/Types.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Solver/Interact.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Types/Basic.hs
- compiler/GHC/Types/Name/Reader.hs
- compiler/GHC/Utils/Outputable.hs
- docs/users_guide/exts/partial_type_signatures.rst
Changes:
=====================================
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 = <stuff>
=====================================
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.
=====================================
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
=====================================
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
-
=====================================
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)
]
=====================================
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
=====================================
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
=====================================
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" $
=====================================
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)
=====================================
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
=====================================
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
=====================================
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:
=====================================
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
=====================================
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.
--
=====================================
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"
=====================================
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.
::
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7f8be3eb3440a152246a1aef7b4020be4c03cf2e
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7f8be3eb3440a152246a1aef7b4020be4c03cf2e
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201029/5cc23c76/attachment-0001.html>
More information about the ghc-commits
mailing list