[commit: ghc] master: Fixed moer tyops (e83d0da)

Gabor Greif ggreif at gmail.com
Thu Apr 25 22:01:44 CEST 2013


Repository : http://darcs.haskell.org/ghc.git/

On branch  : master

https://github.com/ghc/ghc/commit/e83d0dab9981ae6621390d7f9e963eb201780758

>---------------------------------------------------------------

commit e83d0dab9981ae6621390d7f9e963eb201780758
Author: Gabor Greif <ggreif at gmail.com>
Date:   Tue Apr 23 11:24:12 2013 +0200

    Fixed moer tyops

>---------------------------------------------------------------

 compiler/basicTypes/OccName.lhs     |  2 +-
 compiler/deSugar/Match.lhs          |  2 +-
 compiler/iface/IfaceSyn.lhs         |  2 +-
 compiler/llvmGen/Llvm/AbsSyn.hs     | 16 ++++++++--------
 compiler/simplCore/FloatIn.lhs      |  2 +-
 compiler/typecheck/TcSimplify.lhs   |  6 +++---
 compiler/typecheck/TcSplice.lhs     |  2 +-
 docs/comm/the-beast/data-types.html |  4 ++--
 8 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/compiler/basicTypes/OccName.lhs b/compiler/basicTypes/OccName.lhs
index afdde7c..df45cdc 100644
--- a/compiler/basicTypes/OccName.lhs
+++ b/compiler/basicTypes/OccName.lhs
@@ -623,7 +623,7 @@ mkGenR   = mk_simple_deriv tcName "Rep_"
 mkGen1R  = mk_simple_deriv tcName "Rep1_"
 mkGenRCo = mk_simple_deriv tcName "CoRep_"
 
--- data T = MkT ... deriving( Data ) needs defintions for 
+-- data T = MkT ... deriving( Data ) needs definitions for 
 --	$tT   :: Data.Generics.Basics.DataType
 --	$cMkT :: Data.Generics.Basics.Constr
 mkDataTOcc = mk_simple_deriv varName  "$t"
diff --git a/compiler/deSugar/Match.lhs b/compiler/deSugar/Match.lhs
index 43a3af7..3b36441 100644
--- a/compiler/deSugar/Match.lhs
+++ b/compiler/deSugar/Match.lhs
@@ -432,7 +432,7 @@ alternatives, so it adds a default case, as it always does.  A later
 pass may remove it if it's inaccessible.  (See also Note [Empty case
 alternatives] in CoreSyn.)
 
-We do *not* deugar simply to
+We do *not* desugar simply to
    error "empty case" 
 or some such, because 'x' might be bound to (error "hello"), in which
 case we want to see that "hello" exception, not (error "empty case").
diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs
index a0e1a08..e20269b 100644
--- a/compiler/iface/IfaceSyn.lhs
+++ b/compiler/iface/IfaceSyn.lhs
@@ -150,7 +150,7 @@ data IfaceConDecl
         ifConInfix   :: Bool,                   -- True <=> declared infix
         ifConUnivTvs :: [IfaceTvBndr],          -- Universal tyvars
         ifConExTvs   :: [IfaceTvBndr],          -- Existential tyvars
-        ifConEqSpec  :: [(OccName,IfaceType)],  -- Equality contraints
+        ifConEqSpec  :: [(OccName,IfaceType)],  -- Equality constraints
         ifConCtxt    :: IfaceContext,           -- Non-stupid context
         ifConArgTys  :: [IfaceType],            -- Arg types
         ifConFields  :: [OccName],              -- ...ditto... (field labels)
diff --git a/compiler/llvmGen/Llvm/AbsSyn.hs b/compiler/llvmGen/Llvm/AbsSyn.hs
index f5f5eac..1dcd858 100644
--- a/compiler/llvmGen/Llvm/AbsSyn.hs
+++ b/compiler/llvmGen/Llvm/AbsSyn.hs
@@ -264,14 +264,14 @@ data LlvmExpression
 
   {- |
     Inline assembly expression. Syntax is very similar to the style used by GCC.
-      * assembly:   Actual inline assembly code.
-      * contraints: Operand constraints.
-      * return ty:  Return type of function.
-      * vars:       Any variables involved in the assembly code.
-      * sideeffect: Does the expression have side effects not visible from the
-                    constraints list.
-      * alignstack: Should the stack be conservatively aligned before this
-                    expression is executed.
+      * assembly:    Actual inline assembly code.
+      * constraints: Operand constraints.
+      * return ty:   Return type of function.
+      * vars:        Any variables involved in the assembly code.
+      * sideeffect:  Does the expression have side effects not visible from the
+                     constraints list.
+      * alignstack:  Should the stack be conservatively aligned before this
+                     expression is executed.
   -}
   | Asm LMString LMString LlvmType [LlvmVar] Bool Bool
 
diff --git a/compiler/simplCore/FloatIn.lhs b/compiler/simplCore/FloatIn.lhs
index 681c183..0d1c976 100644
--- a/compiler/simplCore/FloatIn.lhs
+++ b/compiler/simplCore/FloatIn.lhs
@@ -256,7 +256,7 @@ course.
 
 Note [extra_fvs (1): avoid floating into RHS]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Consdider let x=\y....t... in body.  We do not necessarily want to float 
+Consider let x=\y....t... in body.  We do not necessarily want to float 
 a binding for t into the RHS, because it'll immediately be floated out
 again.  (It won't go inside the lambda else we risk losing work.)
 In letrec, we need to be more careful still. We don't want to transform
diff --git a/compiler/typecheck/TcSimplify.lhs b/compiler/typecheck/TcSimplify.lhs
index 6d153ca..fbca878 100644
--- a/compiler/typecheck/TcSimplify.lhs
+++ b/compiler/typecheck/TcSimplify.lhs
@@ -137,7 +137,7 @@ go with option (i), implemented at SimplifyTop. Namely:
 Now, that has to do with class defaulting. However there exists type variable /kind/
 defaulting. Again this is done at the top-level and the plan is:
      - At the top-level, once you had a go at solving the constraint, do 
-       figure out /all/ the touchable unification variables of the wanted contraints.
+       figure out /all/ the touchable unification variables of the wanted constraints.
      - Apply defaulting to their kinds
 
 More details in Note [DefaultTyVar].
@@ -456,7 +456,7 @@ situations like
 When inferring a type for 'g', we don't want to apply the
 instance decl, because then we can't satisfy (C t).  So we
 just notice that g isn't quantified over 't' and partition
-the contraints before simplifying.
+the constraints before simplifying.
 
 This only half-works, but then let-generalisation only half-works.
 
@@ -975,7 +975,7 @@ skolem has escaped!
 But it's ok: when we float (Maybe beta[2] ~ gamma[1]), we promote beta[2]
 to beta[1], and that means the (a ~ beta[1]) will be stuck, as it should be.
 
-Previously we tried to "grow" the skol_set with the contraints, to get
+Previously we tried to "grow" the skol_set with the constraints, to get
 all the tyvars that could *conceivably* unify with the skolems, but that
 was far too conservative (Trac #7804). Example: this should be fine:
     f :: (forall a. a -> Proxy x -> Proxy (F x)) -> Int
diff --git a/compiler/typecheck/TcSplice.lhs b/compiler/typecheck/TcSplice.lhs
index 87f35d8..7d51d4b 100644
--- a/compiler/typecheck/TcSplice.lhs
+++ b/compiler/typecheck/TcSplice.lhs
@@ -358,7 +358,7 @@ tcBracket brack res_ty
           -- It's best to simplify the constraint now, even though in
           -- principle some later unification might be useful for it,
           -- because we don't want these essentially-junk TH implication
-          -- contraints floating around nested inside other constraints
+          -- constraints floating around nested inside other constraints
           -- See for example Trac #4949
        ; _binds2 <- simplifyTop lie
 
diff --git a/docs/comm/the-beast/data-types.html b/docs/comm/the-beast/data-types.html
index fef4852..4ec220c 100644
--- a/docs/comm/the-beast/data-types.html
+++ b/docs/comm/the-beast/data-types.html
@@ -147,7 +147,7 @@ top-level nullary constructors (like True and False).  Furthermore,
 what if the code generator encounters a non-saturated application of a
 worker?  E.g. <tt>(map Just xs)</tt>.  We could declare that to be an
 error (CorePrep should saturate them). But instead we currently
-generate a top-level defintion for each constructor worker, whether
+generate a top-level definition for each constructor worker, whether
 nullary or not.  It takes the form:
 <pre>
   MkT{v} = \ p q r -> MkT{v} p q r
@@ -157,7 +157,7 @@ one that generates abstract C and the byte-code generator) treats it as a specia
 allocates a MkT; it does not make a recursive call!  So now there's a top-level curried
 version of the worker which is available to anyone who wants it.
 <p>
-This strange defintion is not emitted into External Core.  Indeed, you might argue that
+This strange definition is not emitted into External Core.  Indeed, you might argue that
 we should instead pass the list of <tt>TyCon</tt>s to the code generator and have it 
 generate magic bindings directly.  As it stands, it's a real hack: see the code in
 CorePrep.mkImplicitBinds.





More information about the ghc-commits mailing list