[Git][ghc/ghc][master] 3 commits: typo

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Wed Sep 7 20:43:00 UTC 2022



Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
d0a2efb2 by Eric Lindblad at 2022-09-07T16:42:45-04:00
typo
- - - - -
fac0098b by Eric Lindblad at 2022-09-07T16:42:45-04:00
typos

- - - - -
a581186f by Eric Lindblad at 2022-09-07T16:42:45-04:00
whitespace

- - - - -


7 changed files:

- compiler/GHC/ByteCode/Instr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Stg/Lint.hs
- compiler/GHC/StgToByteCode.hs
- libraries/base/GHC/Event/Windows.hsc


Changes:

=====================================
compiler/GHC/ByteCode/Instr.hs
=====================================
@@ -300,7 +300,7 @@ instance Outputable BCInstr where
    ppr CASEFAIL              = text "CASEFAIL"
    ppr (JMP lab)             = text "JMP"      <+> ppr lab
    ppr (CCALL off marshall_addr flags) = text "CCALL   " <+> ppr off
-                                                <+> text "marshall code at"
+                                                <+> text "marshal code at"
                                                <+> text (show marshall_addr)
                                                <+> (case flags of
                                                       0x1 -> text "(interruptible)"


=====================================
compiler/GHC/Core/Opt/Specialise.hs
=====================================
@@ -307,7 +307,7 @@ only it knows how to build the dictionaries d1 and d2!  For example
 Here, the specialised version of g is an application of g's rhs to the
 Ord dictionary for (Tree Int), which only the type checker can conjure
 up.  There might not even *be* one, if (Tree Int) is not an instance of
-Ord!  (All the other specialision has suitable dictionaries to hand
+Ord!  (All the other specialisation has suitable dictionaries to hand
 from actual calls.)
 
 Problem.  The type checker doesn't have to hand a convenient <f_rhs>, because
@@ -1335,7 +1335,7 @@ specBind top_lvl env (NonRec fn rhs) do_body
 
              fn3 = zapIdDemandInfo fn2
              -- We zap the demand info because the binding may float,
-             -- which would invaidate the demand info (see #17810 for example).
+             -- which would invalidate the demand info (see #17810 for example).
              -- Destroying demand info is not terrible; specialisation is
              -- always followed soon by demand analysis.
 


=====================================
compiler/GHC/Core/Rules.hs
=====================================
@@ -153,7 +153,7 @@ Note [Overall plumbing for rules]
 
   In a single simplifier run new rules can be added into the EPS so it matters
   to keep an up-to-date view of which rules have been loaded. For examples of
-  where this went wrong and caused cryptic performance regressions seee
+  where this went wrong and caused cryptic performance regressions
   see T19790 and !6735.
 
 
@@ -971,7 +971,7 @@ match renv subst e1 (Var v2) mco  -- Note [Expanding variables]
 -- Note the match on MRefl!  We fail if there is a cast in the target
 --     (e1 e2) ~ (d1 d2) |> co
 -- See Note [Cancel reflexive casts]: in the Cast equations for 'match'
--- we agressively ensure that if MCo is reflective, it really is MRefl.
+-- we aggressively ensure that if MCo is reflective, it really is MRefl.
 match renv subst (App f1 a1) (App f2 a2) MRefl
   = do  { subst' <- match renv subst f1 f2 MRefl
         ; match renv subst' a1 a2 MRefl }
@@ -1150,7 +1150,7 @@ when we eta-reduce (\a b. blah a b) to 'blah', we'll get
 and we really want to spot that the co/sym-co cancels out.
 Hence
   * We keep an invariant that the MCoercion is always MRefl
-    if the MCoercion is reflextve
+    if the MCoercion is reflexive
   * We maintain this invariant via the call to checkReflexiveMCo
     in the Cast case of 'match'.
 -}


=====================================
compiler/GHC/CoreToStg/Prep.hs
=====================================
@@ -129,7 +129,7 @@ The goal of this pass is to prepare for code generation.
     annotate according to scoping rules when floating.
 
 11. Collect cost centres (including cost centres in unfoldings) if we're in
-    profiling mode. We have to do this here beucase we won't have unfoldings
+    profiling mode. We have to do this here because we won't have unfoldings
     after this pass (see `trimUnfolding` and Note [Drop unfoldings and rules].
 
 12. Eliminate case clutter in favour of unsafe coercions.
@@ -179,7 +179,7 @@ CorePrep does these two transformations:
    Tiresome, but not difficult.
 
 These transformations get rid of "case clutter", leaving only casts.
-We are doing no further significant tranformations, so the reasons
+We are doing no further significant transformations, so the reasons
 for the case forms have disappeared. And it is extremely helpful for
 the ANF-ery, CoreToStg, and backends, if trivial expressions really do
 look trivial. #19700 was an example.
@@ -2028,7 +2028,7 @@ enterRecGroupRHSs env grp
 {- Note [CpeTyCoEnv]
 ~~~~~~~~~~~~~~~~~~~~
 The cpe_tyco_env :: Maybe CpeTyCoEnv field carries a substitution
-for type and coercion varibles
+for type and coercion variables
 
 * We need the coercion substitution to support the elimination of
   unsafeEqualityProof (see Note [Unsafe coercions])


=====================================
compiler/GHC/Stg/Lint.hs
=====================================
@@ -68,8 +68,8 @@ is much coarser. In particular, STG programs must be /well-kinded/.
 More precisely, if f :: ty1 -> ty2, then in the application (f e)
 where e :: ty1', we must have kind(ty1) = kind(ty1').
 
-So the STG type system does not distinguish beteen Int and Bool,
-but it /does/ distinguish beteen Int and Int#, because they have
+So the STG type system does not distinguish between Int and Bool,
+but it /does/ distinguish between Int and Int#, because they have
 different kinds.  Actually, since all terms have kind (TYPE rep),
 we might say that the STG language is well-runtime-rep'd.
 
@@ -356,7 +356,7 @@ lintStgAppReps fun args = do
         | and $ zipWith (primRepCompatible platform) actual_rep expected_rep
         = match_args actual_reps_left expected_reps_left
 
-        | otherwise = addErrL $ hang (text "Function type reps and function argument reps missmatched") 2 $
+        | otherwise = addErrL $ hang (text "Function type reps and function argument reps mismatched") 2 $
             (text "In application " <> ppr fun <+> ppr args $$
               text "argument rep:" <> ppr actual_rep $$
               text "expected rep:" <> ppr expected_rep $$


=====================================
compiler/GHC/StgToByteCode.hs
=====================================
@@ -1330,7 +1330,7 @@ generateCCall d0 s p (CCallSpec target cconv safety) result_ty args_r_to_l
             Addr# address_of_C_fn
             <placeholder-for-result#> (must be an unboxed type)
 
-         The interpreter then calls the marshall code mentioned
+         The interpreter then calls the marshal code mentioned
          in the CCALL insn, passing it (& <placeholder-for-result#>),
          that is, the addr of the topmost word in the stack.
          When this returns, the placeholder will have been


=====================================
libraries/base/GHC/Event/Windows.hsc
=====================================
@@ -1039,7 +1039,7 @@ step maxDelay mgr at Manager{..} = do
 -- before adding something to the work queue.
 --
 -- Thread safety: This function atomically replaces outstanding events with
--- a pointer to nullReq. This means it's safe (but potentially wastefull) to
+-- a pointer to nullReq. This means it's safe (but potentially wasteful) to
 -- have two concurrent or parallel invocations on the same array.
 processCompletion :: Manager -> Int -> Maybe Seconds -> IO (Bool, Maybe Seconds)
 processCompletion Manager{..} n delay = do



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/808bb7934e1e3007bf7115bdf75263bba937c85b...a581186f38a4feb850614b03f452191eaceee14d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/808bb7934e1e3007bf7115bdf75263bba937c85b...a581186f38a4feb850614b03f452191eaceee14d
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/20220907/774e2b5f/attachment-0001.html>


More information about the ghc-commits mailing list