diff options
Diffstat (limited to 'compiler/GHC/Tc')
39 files changed, 101 insertions, 101 deletions
diff --git a/compiler/GHC/Tc/Deriv.hs b/compiler/GHC/Tc/Deriv.hs index f12fefcffe..0a873ff05e 100644 --- a/compiler/GHC/Tc/Deriv.hs +++ b/compiler/GHC/Tc/Deriv.hs @@ -1632,7 +1632,7 @@ e.g. newtype S1 = S1 [T1 ()] newtype T1 a = T1 (StateT S1 IO a ) deriving( Monad ) Remember, too, that type families are currently (conservatively) given a recursive flag, so this also allows newtype deriving to work -for type famillies. +for type families. We used to exclude recursive types, because we had a rather simple minded way of generating the instance decl: diff --git a/compiler/GHC/Tc/Deriv/Generate.hs b/compiler/GHC/Tc/Deriv/Generate.hs index 4cacf36013..49d97e81e1 100644 --- a/compiler/GHC/Tc/Deriv/Generate.hs +++ b/compiler/GHC/Tc/Deriv/Generate.hs @@ -452,7 +452,7 @@ gen_Ord_binds loc dit@(DerivInstTys{ dit_rep_tc = tycon = nlHsCase (nlHsVar a_RDR) $ map (mkOrdOpAlt op) tycon_data_cons -- i.e. case a of { C1 x y -> case b of C1 x y -> ....compare x,y... - -- C2 x -> case b of C2 x -> ....comopare x.... } + -- C2 x -> case b of C2 x -> ....compare x.... } | null non_nullary_cons -- All nullary, so go straight to comparing tags = mkTagCmp op diff --git a/compiler/GHC/Tc/Deriv/Generics.hs b/compiler/GHC/Tc/Deriv/Generics.hs index 85a73274ce..2c7639c3a9 100644 --- a/compiler/GHC/Tc/Deriv/Generics.hs +++ b/compiler/GHC/Tc/Deriv/Generics.hs @@ -1056,7 +1056,7 @@ is usually too small for GHC to do that. The recommended approach thus far was to increase unfolding threshold, but this makes GHC inline more aggressively in general, whereas it should only be more -aggresive with generics-based code. +aggressive with generics-based code. The solution is to use a heuristic that'll annotate Generic class methods with INLINE[1] pragmas (the explicit phase is used to give users phase control as diff --git a/compiler/GHC/Tc/Errors.hs b/compiler/GHC/Tc/Errors.hs index 35deaf06bc..6d0bf4d117 100644 --- a/compiler/GHC/Tc/Errors.hs +++ b/compiler/GHC/Tc/Errors.hs @@ -1484,7 +1484,7 @@ mkIPErr ctxt items ---------------- -- | Report a representation-polymorphism error to the user: --- a type is required to havehave a fixed runtime representation, +-- a type is required to have a fixed runtime representation, -- but doesn't. -- -- See Note [Reporting representation-polymorphism errors] in GHC.Tc.Types.Origin. diff --git a/compiler/GHC/Tc/Errors/Hole.hs b/compiler/GHC/Tc/Errors/Hole.hs index f0a8e7aa8e..1011144afc 100644 --- a/compiler/GHC/Tc/Errors/Hole.hs +++ b/compiler/GHC/Tc/Errors/Hole.hs @@ -400,7 +400,7 @@ is discarded. Note [Speeding up valid hole-fits] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To fix #16875 we noted that a lot of time was being spent on uneccessary work. +To fix #16875 we noted that a lot of time was being spent on unecessary work. When we'd call `tcCheckHoleFit hole hole_ty ty`, we would end up by generating a constraint to show that `hole_ty ~ ty`, including any constraints in `ty`. For diff --git a/compiler/GHC/Tc/Errors/Types.hs b/compiler/GHC/Tc/Errors/Types.hs index a6125e7dfc..16d91f1c44 100644 --- a/compiler/GHC/Tc/Errors/Types.hs +++ b/compiler/GHC/Tc/Errors/Types.hs @@ -144,7 +144,7 @@ one for the context and one for any supplementary information. Consider the foll Under the hood, the reporting functions in Tc.Utils.Monad were emitting "Couldn't match" as the important part, "In the expression" as the context and "In a stmt..In the expression" as the supplementary, with the context and supplementary usually smashed together so that -the final message would be composed only by two SDoc (which would then be bulletted like in +the final message would be composed only by two SDoc (which would then be bulleted like in the example). In order for us to smooth out the migration to the new diagnostic infrastructure, we @@ -331,7 +331,7 @@ data TcRnMessage where Test cases: plugins/T19926 -} TcRnUnsafeDueToPlugin :: TcRnMessage - {-| TcRnModMissingRealSrcSpan is an error that occurrs when compiling a module that lacks + {-| TcRnModMissingRealSrcSpan is an error that occurs when compiling a module that lacks an associated 'RealSrcSpan'. Test cases: None @@ -2128,7 +2128,7 @@ data TcRnMessage where -> !(NE.NonEmpty (LocatedA InlinePragma)) -- ^ Other pragmas -> TcRnMessage - {- TcRnUnexpectedPragmas is a warning that occurrs when unexpected pragmas appear + {- TcRnUnexpectedPragmas is a warning that occurs when unexpected pragmas appear in the source. Example(s): @@ -2150,7 +2150,7 @@ data TcRnMessage where -} TcRnNonOverloadedSpecialisePragma :: !(LIdP GhcRn) -> TcRnMessage - {- TcRnSpecialiseNotVisible is a warning that occurrs when the subject of a + {- TcRnSpecialiseNotVisible is a warning that occurs when the subject of a SPECIALISE pragma has a definition that is not visible from the current module. Example(s): none @@ -2481,7 +2481,7 @@ data DeriveInstanceErrReason !DeriveAnyClassEnabled -- ^ Whether or not -XDeriveAnyClass is enabled -- already. - -- | Stock deriving won't work, but perhas DeriveAnyClass will. + -- | Stock deriving won't work, but perhaps DeriveAnyClass will. | DerivErrNotDeriveable !DeriveAnyClassEnabled -- | The given 'PredType' is not a class. | DerivErrNotAClass !PredType @@ -2884,7 +2884,7 @@ data TcSolverReportMsg | FixedRuntimeRepError [FixedRuntimeRepErrorInfo] -- | An equality between two types is blocked on a kind equality - -- beteen their kinds. + -- between their kinds. -- -- Test cases: none. | BlockedEquality ErrorItem @@ -3162,7 +3162,7 @@ data NotInScopeError -- Test cases: annfail01, annfail02, annfail11. | NoTopLevelBinding - -- | A class doesnt have a method with this name, + -- | A class doesn't have a method with this name, -- or, a class doesn't have an associated type with this name, -- or, a record doesn't have a record field with this name. | UnknownSubordinate SDoc @@ -3270,7 +3270,7 @@ data RelevantBindings -- | Display some relevant bindings. pprRelevantBindings :: RelevantBindings -> SDoc -- This function should be in "GHC.Tc.Errors.Ppr", --- but's it's here for the moment as it's needed in "GHC.Tc.Errors". +-- but it's here for the moment as it's needed in "GHC.Tc.Errors". pprRelevantBindings (RelevantBindings bds ran_out_of_fuel) = ppUnless (null rel_bds) $ hang (text "Relevant bindings include") diff --git a/compiler/GHC/Tc/Gen/App.hs b/compiler/GHC/Tc/Gen/App.hs index 4f04e82cf2..7d64f0d1ef 100644 --- a/compiler/GHC/Tc/Gen/App.hs +++ b/compiler/GHC/Tc/Gen/App.hs @@ -86,7 +86,7 @@ Some notes relative to the paper * When QL is done, we don't need to turn the un-filled-in instantiation variables into unification variables -- they - already /are/ unification varibles! See also + already /are/ unification variables! See also Note [Instantiation variables are short lived]. * We cleverly avoid the quadratic cost of QL, alluded to in the paper. @@ -216,7 +216,7 @@ Fig 3, plus the modification in Fig 5, of the QL paper: It treats application chains (f e1 @ty e2) specially: -* So we can report errors like "in the third arument of a call of f" +* So we can report errors like "in the third argument of a call of f" * So we can do Visible Type Application (VTA), for which we must not eagerly instantiate the function part of the application. @@ -1060,7 +1060,7 @@ qlUnify delta ty1 ty2 ; writeMetaTyVar kappa (mkCastTy ty2 co) } | otherwise - = return () -- Occurs-check or forall-bound varialbe + = return () -- Occurs-check or forall-bound variable {- Note [Actual unification in qlUnify] @@ -1085,7 +1085,7 @@ That is the entire point of qlUnify! Wrinkles: * What if kappa and ty have different kinds? We solve that problem by calling unifyKind, producing a coercion perhaps emitting some deferred equality constraints. That is /different/ from the approach we use in - the main constraint solver for herterogeneous equalities; see Note + the main constraint solver for heterogeneous equalities; see Note [Equalities with incompatible kinds] in Solver.Canonical Why different? Because: diff --git a/compiler/GHC/Tc/Gen/Bind.hs b/compiler/GHC/Tc/Gen/Bind.hs index d13b3b197c..fedea75796 100644 --- a/compiler/GHC/Tc/Gen/Bind.hs +++ b/compiler/GHC/Tc/Gen/Bind.hs @@ -1153,7 +1153,7 @@ Consider this from #18646 We get [W] Foo (), [W] Applicative f. When we do pickCapturedPreds in choose_psig_context, we'll discard Foo ()! Usually would not quantify over such (closed) predicates. So my_theta will be (Applicative f). But we really -do want to quantify over (Foo ()) -- it was speicfied by the programmer. +do want to quantify over (Foo ()) -- it was specified by the programmer. Solution: always return annotated_theta (user-specified) plus the extra piece diff_theta. @@ -1354,7 +1354,7 @@ with -XImpredicativeTypes we can infer a good type for (combine head ids), and use that to tell us the polymorphic types of x and y. -We don't need to check -XImpredicativeTypes beucase without it +We don't need to check -XImpredicativeTypes because without it these types like [forall a. a->a] are illegal anyway, so this special case code only really has an effect if -XImpredicativeTypes is on. Small exception: diff --git a/compiler/GHC/Tc/Gen/Export.hs b/compiler/GHC/Tc/Gen/Export.hs index efc6433f29..d42ee046b5 100644 --- a/compiler/GHC/Tc/Gen/Export.hs +++ b/compiler/GHC/Tc/Gen/Export.hs @@ -125,7 +125,7 @@ are both type constructors into two GRES. , T defined at A.hs:4:23 ] Then, we get @[C{C;}, C{T;}, T{T;}, T{D;}]@, which eventually gets merged -into @[C{C, T;}, T{T, D;}]@ (which satsifies the AvailTC invariant). +into @[C{C, T;}, T{T, D;}]@ (which satisfies the AvailTC invariant). -} data ExportAccum -- The type of the accumulating parameter of @@ -758,4 +758,4 @@ exportClashErr global_env child1 child2 ie1 ie2 case SrcLoc.leftmost_smallest (greSrcSpan gre1) (greSrcSpan gre2) of LT -> (child1, gre1, ie1, child2, gre2, ie2) GT -> (child2, gre2, ie2, child1, gre1, ie1) - EQ -> panic "exportClashErr: clashing exports have idential location" + EQ -> panic "exportClashErr: clashing exports have identical location" diff --git a/compiler/GHC/Tc/Gen/Expr.hs b/compiler/GHC/Tc/Gen/Expr.hs index 6a4eb7f6f1..c5c5616024 100644 --- a/compiler/GHC/Tc/Gen/Expr.hs +++ b/compiler/GHC/Tc/Gen/Expr.hs @@ -185,7 +185,7 @@ tcPolyExpr expr res_ty tcExpr :: HsExpr GhcRn -> ExpRhoType -> TcM (HsExpr GhcTc) --- Use tcApp to typecheck appplications, which are treated specially +-- Use tcApp to typecheck applications, which are treated specially -- by Quick Look. Specifically: -- - HsVar lone variables, to ensure that they can get an -- impredicative instantiation (via Quick Look @@ -287,7 +287,7 @@ tcExpr e@(HsLamCase x lc_variant matches) res_ty ************************************************************************ -} --- Explict lists [e1,e2,e3] have been expanded already in the renamer +-- Explicit lists [e1,e2,e3] have been expanded already in the renamer -- The expansion includes an ExplicitList, but it is always the built-in -- list type, so that's all we need concern ourselves with here. See -- GHC.Rename.Expr. Note [Handling overloaded and rebindable constructs] @@ -1306,7 +1306,7 @@ desugarRecordUpd record_expr rbnds res_ty ; nm <- newNameAt nm_occ generatedSrcSpan ; let id = mkLocalId nm m actual_arg_ty -- NB: create fresh names to avoid any accidental shadowing - -- occuring in the RHS expressions when creating the let bindings: + -- occurring in the RHS expressions when creating the let bindings: -- -- let x1 = e1; x2 = e2; ... ; return (fld_nm, (id, rhs)) diff --git a/compiler/GHC/Tc/Gen/Foreign.hs b/compiler/GHC/Tc/Gen/Foreign.hs index 0f1c9084d7..57b30c9548 100644 --- a/compiler/GHC/Tc/Gen/Foreign.hs +++ b/compiler/GHC/Tc/Gen/Foreign.hs @@ -96,7 +96,7 @@ declaration. If we have newtype Age = MkAge Int we want to see that Age -> IO () is the same as Int -> IO (). But, we don't -need to recur on any type parameters, because no paramaterized types (with +need to recur on any type parameters, because no parameterized types (with interesting parameters) are marshalable! The full list of marshalable types is in the body of boxedMarshalableTyCon in GHC.Tc.Utils.TcType. The only members of that list not at kind * are Ptr, FunPtr, and StablePtr, all of which get marshaled diff --git a/compiler/GHC/Tc/Gen/Head.hs b/compiler/GHC/Tc/Gen/Head.hs index dd67b7f2b2..6341aecf8d 100644 --- a/compiler/GHC/Tc/Gen/Head.hs +++ b/compiler/GHC/Tc/Gen/Head.hs @@ -956,7 +956,7 @@ tcExprSig _ expr sig@(PartialSig { psig_name = name, sig_loc = loc }) {- Note [Partial expression signatures] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Partial type signatures on expressions are easy to get wrong. But -here is a guiding principile +here is a guiding principle e :: ty should behave like let x :: ty diff --git a/compiler/GHC/Tc/Gen/HsType.hs b/compiler/GHC/Tc/Gen/HsType.hs index 3fed598f4d..c6deae4be2 100644 --- a/compiler/GHC/Tc/Gen/HsType.hs +++ b/compiler/GHC/Tc/Gen/HsType.hs @@ -336,7 +336,7 @@ than the surrounding context.) This kappa cannot be solved for while checking the pattern signature (which is not kind-generalized). When we are checking the *body* of foo, though, we need to unify the type of x with the argument type of bar. At this point, the ambient TcLevel is 1, and spotting a -matavariable with level 2 would violate the (WantedInv) invariant of +metavariable with level 2 would violate the (WantedInv) invariant of Note [TcLevel invariants]. So, instead of kind-generalizing, we promote the metavariable to level 1. This is all done in kindGeneralizeNone. @@ -1320,7 +1320,7 @@ This table summarises this relation: | f :: forall {a}. type HsForAllInvis InferredSpec Inferred | f :: forall a -> type HsForAllVis SpecifiedSpec Required | f :: forall {a} -> type HsForAllVis InferredSpec / -| This last form is non-sensical and is thus rejected. +| This last form is nonsensical and is thus rejected. ---------------------------------------------------------------------------- For more information regarding the interpretation of the resulting ArgFlag, see @@ -2447,7 +2447,7 @@ kcInferDeclHeader kcInferDeclHeader name flav (HsQTvs { hsq_ext = kv_ns , hsq_explicit = hs_tvs }) kc_res_ki - -- No standalane kind signature and no CUSK. + -- No standalone kind signature and no CUSK. -- See Note [Required, Specified, and Inferred for types] in GHC.Tc.TyCl = addTyConFlavCtxt name flav $ do { (scoped_kvs, (tc_tvs, res_kind)) @@ -2616,7 +2616,7 @@ matchUpSigWithDecl -- Argument is excess TyConBinders and tail kind -> TcM ( [TcTyConBinder] -- Skolemised binders, with TcTyVars , a ) --- See Note [Matching a kind sigature with a declaration] +-- See Note [Matching a kind signature with a declaration] -- Invariant: Length of returned TyConBinders + length of excess TyConBinders -- = length of incoming TyConBinders matchUpSigWithDecl sig_tcbs sig_res_kind hs_bndrs thing_inside @@ -3505,7 +3505,7 @@ bindTyClTyVarsAndZonk tycon_name thing_inside zonkAndScopedSort :: [TcTyVar] -> TcM [TcTyVar] zonkAndScopedSort spec_tkvs = do { spec_tkvs <- zonkTcTyVarsToTcTyVars spec_tkvs - -- Zonk the kinds, to we can do the dependency analayis + -- Zonk the kinds, to we can do the dependency analysis -- Do a stable topological sort, following -- Note [Ordering of implicit variables] in GHC.Rename.HsType @@ -3603,7 +3603,7 @@ We must * Find the free variables with level > i, in this case gamma[i] * Skolemise those free variables and quantify over them, giving f :: forall g. beta[i-1] -> g - * Emit the residiual constraint wrapped in an implication for g, + * Emit the residual constraint wrapped in an implication for g, thus forall g. WC All of this happens for types too. Consider @@ -4063,7 +4063,7 @@ we do the following * Just as for ordinary signatures, we must solve local equalities and zonk the type after kind-checking it, to ensure that all the nested - forall binders can "see" their occurrenceds + forall binders can "see" their occurrences Just as for ordinary signatures, this zonk also gets any Refl casts out of the way of instantiation. Example: #18008 had diff --git a/compiler/GHC/Tc/Gen/Sig.hs b/compiler/GHC/Tc/Gen/Sig.hs index 4bb9a8038d..138e61978c 100644 --- a/compiler/GHC/Tc/Gen/Sig.hs +++ b/compiler/GHC/Tc/Gen/Sig.hs @@ -112,7 +112,7 @@ especially on value bindings. Here's an overview. but for /partial/ signatures it starts from the HsSyn, so it has to kind-check it etc: tcHsPartialSigType. It's convenient to do this at the same time as instantiation, because we can - make the wildcards into unification variables right away, raather + make the wildcards into unification variables right away, rather than somehow quantifying over them. And the "TcLevel" of those unification variables is correct because we are in tcMonoBinds. diff --git a/compiler/GHC/Tc/Gen/Splice.hs b/compiler/GHC/Tc/Gen/Splice.hs index 027ae27aff..47d19c127b 100644 --- a/compiler/GHC/Tc/Gen/Splice.hs +++ b/compiler/GHC/Tc/Gen/Splice.hs @@ -449,7 +449,7 @@ RENAMER (rnUntypedBracket): SplicePointName, 'spn' * The SplicePointName connects the `PendingRnSplice` with the particular point - in the syntax tree where that expresion should be spliced in. That point + in the syntax tree where that expression should be spliced in. That point in the tree is identified by `(HsUntypedSpliceNested spn)`. It is used by the desugarer, so that we ultimately generate something like let spn = g x diff --git a/compiler/GHC/Tc/Instance/Family.hs b/compiler/GHC/Tc/Instance/Family.hs index 8b76c9f4cd..4a575d614e 100644 --- a/compiler/GHC/Tc/Instance/Family.hs +++ b/compiler/GHC/Tc/Instance/Family.hs @@ -364,7 +364,7 @@ checkFamInstConsistency directlyImpMods -- We could, but doing so means one of two things: -- -- 1. When looping over the cartesian product we convert - -- a set into a non-deterministicly ordered list. Which + -- a set into a non-deterministically ordered list. Which -- happens to be fine for interface file determinism -- in this case, today, because the order only -- determines the order of deferred checks. But such diff --git a/compiler/GHC/Tc/Instance/FunDeps.hs b/compiler/GHC/Tc/Instance/FunDeps.hs index b11ed10efc..710750a57d 100644 --- a/compiler/GHC/Tc/Instance/FunDeps.hs +++ b/compiler/GHC/Tc/Instance/FunDeps.hs @@ -633,7 +633,7 @@ In checkFunDeps we check that a new ClsInst is consistent with all the ClsInsts in the environment. The bogus aspect is discussed in #10675. Currently it if the two -types are *contradicatory*, using (isNothing . tcUnifyTys). But all +types are *contradictory*, using (isNothing . tcUnifyTys). But all the papers say we should check if the two types are *equal* thus not (substTys subst rtys1 `eqTypes` substTys subst rtys2) For now I'm leaving the bogus form because that's the way it has diff --git a/compiler/GHC/Tc/Instance/Typeable.hs b/compiler/GHC/Tc/Instance/Typeable.hs index 3dc6154c84..3c5343722e 100644 --- a/compiler/GHC/Tc/Instance/Typeable.hs +++ b/compiler/GHC/Tc/Instance/Typeable.hs @@ -106,7 +106,7 @@ There are many wrinkles: * GHC.Prim doesn't have any associated object code, so we need to put the representations for types defined in this module elsewhere. We chose this place to be GHC.Types. GHC.Tc.Instance.Typeable.mkPrimTypeableBinds is responsible for - injecting the bindings for the GHC.Prim representions when compiling + injecting the bindings for the GHC.Prim representations when compiling GHC.Types. * TyCon.tyConRepModOcc is responsible for determining where to find diff --git a/compiler/GHC/Tc/Module.hs b/compiler/GHC/Tc/Module.hs index aa4d18b8cc..abc4031df0 100644 --- a/compiler/GHC/Tc/Module.hs +++ b/compiler/GHC/Tc/Module.hs @@ -1275,7 +1275,7 @@ checkBootTyCon is_boot tc1 tc2 -- but ONLY if the type synonym is nullary and has no type family -- applications. This arises from two properties of skolem abstract data: -- - -- For any T (with some number of paramaters), + -- For any T (with some number of parameters), -- -- 1. T is a valid type (it is "curryable"), and -- @@ -2727,7 +2727,7 @@ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0179-printi :type / TM_Inst - In this mode, we report the type obained by instantiating only the + In this mode, we report the type obtained by instantiating only the /inferred/ quantifiers of e's type, solving constraints, and re-generalising, as discussed in #11376. diff --git a/compiler/GHC/Tc/Solver.hs b/compiler/GHC/Tc/Solver.hs index 3ae3836624..6f783a6182 100644 --- a/compiler/GHC/Tc/Solver.hs +++ b/compiler/GHC/Tc/Solver.hs @@ -438,7 +438,7 @@ Our solution is this: We re-emit the implication rather than reporting the errors right now, -so that the error mesages are improved by other solving and defaulting. +so that the error messages are improved by other solving and defaulting. e.g. we prefer Cannot match 'Type->Type' with 'Type' to Cannot match 'Type->Type' with 'TYPE r0' @@ -1013,7 +1013,7 @@ We could do more than once but we'd have to have /some/ limit: in the the recursive case, we would go on forever in the common case where the constraints /are/ satisfiable (#10592 comment:12!). -For stratightforard situations without type functions the try_harder +For straightforward situations without type functions the try_harder step does nothing. Note [tcNormalise] @@ -1668,13 +1668,13 @@ We will ultimately quantify f over (Eq a, C a, <diff>), where At least for single functions we would like to quantify f over precisely the same theta as <quant-theta>, so that we get to take the short-cut path in GHC.Tc.Gen.Bind.mkExport, and avoid calling -tcSubTypeSigma for impedence matching. Why avoid? Because it falls +tcSubTypeSigma for impedance matching. Why avoid? Because it falls over for ambiguous types (#20921). We can get precisely the same theta by using the same algorithm, findInferredDiff. -All of this goes wrong if we have (a) mutual recursion, (b) mutiple +All of this goes wrong if we have (a) mutual recursion, (b) multiple partial type signatures, (c) with different constraints, and (d) ambiguous types. Something like f :: forall a. Eq a => F a -> _ @@ -1848,7 +1848,7 @@ defaultTyVarsAndSimplify rhs_tclvl mono_tvs candidates -- NB: only pass 'DefaultKindVars' when we know we're dealing with a kind variable. tv - -- this common case (no inferred contraints) should be fast + -- this common case (no inferred constraints) should be fast simplify_cand [] = return [] -- see Note [Unconditionally resimplify constraints when quantifying] simplify_cand candidates diff --git a/compiler/GHC/Tc/Solver/Canonical.hs b/compiler/GHC/Tc/Solver/Canonical.hs index ec8e11b168..86569a8109 100644 --- a/compiler/GHC/Tc/Solver/Canonical.hs +++ b/compiler/GHC/Tc/Solver/Canonical.hs @@ -412,7 +412,7 @@ Examples of how adding superclasses can help: instance L (Maybe a) a When solving the superclasses of the (C (Maybe a) a) instance, we get - [G] C a b, and hance by superclasses, [G] G a, [G] L a b + [G] C a b, and hence by superclasses, [G] G a, [G] L a b [W] G (Maybe a) Use the instance decl to get [W] C a beta @@ -590,7 +590,7 @@ mk_strict_superclasses rec_clss (CtGiven { ctev_evar = evar, ctev_loc = loc }) -- GHC.Tc.TyCl.Instance. Skip for a tiny performance win. -- See Note [Solving superclass constraints] in GHC.Tc.TyCl.Instance - -- for explantation of InstSCOrigin and Note [Replacement vs keeping] in + -- for explanation of InstSCOrigin and Note [Replacement vs keeping] in -- GHC.Tc.Solver.Interact for why we need OtherSCOrigin and depths | otherwise = loc { ctl_origin = new_orig } @@ -1179,7 +1179,7 @@ respect typechecker equality. sameVis puts both forms of invisible type variable binders into the same equivalence class. Note that we do /not/ use sameVis in GHC.Core.Type.eqType, which implements -/definitional/ equality, a slighty more coarse-grained notion of equality +/definitional/ equality, a slightly more coarse-grained notion of equality (see Note [Non-trivial definitional equality] in GHC.Core.TyCo.Rep) that does not consider the ArgFlag of ForAllTys at all. That is, eqType would equate all of forall k. <...>, forall {k}. <...>, and forall k -> <...>. @@ -1972,7 +1972,7 @@ If we see (T s1 t1 ~ T s2 t2), then we can just decompose to (s1 ~ s2, t1 ~ t2) and push those back into the work list. But if s1 = K k1 s2 = K k2 -then we will just decomopose s1~s2, and it might be better to +then we will just decompose s1~s2, and it might be better to do so on the spot. An important special case is where s1=s2, and we get just Refl. @@ -2827,7 +2827,7 @@ Details: (5) The approach here is inefficient because it replaces every (outermost) type family application with a type variable, regardless of whether that particular appplication is implicated in the occurs check. An alternative - would be to replce only type-family applications that meantion the offending LHS. + would be to replce only type-family applications that mention the offending LHS. For instance, we could choose to affect only type family applications that mention the offending LHS: e.g. in a ~ (F b, G a), we need to replace only G a, not F b. Furthermore, diff --git a/compiler/GHC/Tc/Solver/InertSet.hs b/compiler/GHC/Tc/Solver/InertSet.hs index 4de3ca8d1f..c1f173ee14 100644 --- a/compiler/GHC/Tc/Solver/InertSet.hs +++ b/compiler/GHC/Tc/Solver/InertSet.hs @@ -338,7 +338,7 @@ VERY IMPORTANT INVARIANT: in the above sense - Exception 1: local quantified constraints have no such guarantee; - indeed, adding a "solved dictionary" when appling a quantified + indeed, adding a "solved dictionary" when applying a quantified constraint led to the ability to define unsafeCoerce in #17267. @@ -883,7 +883,7 @@ The idea is that (this is Lemma (L0)), and hence this triple never plays a role in application S(f,t). It is always safe to extend S with such a triple. - (NB: we could strengten K1) in this way too, but see K3. + (NB: we could strengthen K1) in this way too, but see K3. - (K2b): if lhs not in s, we have no further opportunity to apply the work item diff --git a/compiler/GHC/Tc/Solver/Interact.hs b/compiler/GHC/Tc/Solver/Interact.hs index ac29f55505..59723cfe70 100644 --- a/compiler/GHC/Tc/Solver/Interact.hs +++ b/compiler/GHC/Tc/Solver/Interact.hs @@ -76,7 +76,7 @@ Note [Basic Simplifier Plan] - inert reactions - spontaneous reactions - top-level interactions - Each stage returns a StopOrContinue and may have sideffected + Each stage returns a StopOrContinue and may have sideeffected the inerts or worklist. The threading of the stages is as follows: @@ -912,7 +912,7 @@ Note that: cannot be solved from instances. * The (EvBindMap, DictMap CtEvidence) is an accumulating purely-functional - state that allows try_solve_from_instance to augmennt the evidence + state that allows try_solve_from_instance to augment the evidence bindings and inert_solved_dicts as it goes. If it succeeds, we commit all these bindings and solved dicts to the @@ -985,7 +985,7 @@ We ingore such fundeps for several reasons: [W] iss ~ is2 : beta Again we can't prove that equality; and worse we'll rewrite iss to - (is2:beta) in deeply nested contraints inside this implication, + (is2:beta) in deeply nested constraints inside this implication, where beta is untouchable (under other equality constraints), leading to other insoluble constraints. @@ -1460,7 +1460,7 @@ But it's not so simple: That first argument is invisible in the source program (aside from visible type application), so we'd much prefer to get the error from - the second. We track visiblity in the uo_visible field of a TypeEqOrigin. + the second. We track visibility in the uo_visible field of a TypeEqOrigin. We use this to prioritise visible errors (see GHC.Tc.Errors.tryReporters, the partition on isVisibleOrigin). @@ -1810,7 +1810,7 @@ as the fundeps. -} doTopFundepImprovement :: Ct -> TcS (StopOrContinue Ct) --- Try to functional-dependency improvement betweeen the constraint +-- Try to functional-dependency improvement between the constraint -- and the top-level instance declarations -- See Note [Fundeps with instances] -- See also Note [Weird fundeps] @@ -2432,7 +2432,7 @@ And less obviously to: instance (c1, c2) => (% c1, c2 %) Example in #14218 -Exammples: T5853, T10432, T5315, T9222, T2627b, T3028b +Examples: T5853, T10432, T5315, T9222, T2627b, T3028b PS: the term "naturally coherent" doesn't really seem helpful. Perhaps "invertible" or something? I left it for now though. @@ -2457,7 +2457,7 @@ will be constructed by GHC at a call site... from the very instances that unify with it here. It is not like an incoherent user-written instance which might have utterly different behaviour. -Consdider f :: Eq a => blah. If we have [W] Eq a, we certainly +Consider f :: Eq a => blah. If we have [W] Eq a, we certainly get it from the Eq a context, without worrying that there are lots of top-level instances that unify with [W] Eq a! We'll use those instances to build evidence to pass to f. That's just the diff --git a/compiler/GHC/Tc/Solver/Monad.hs b/compiler/GHC/Tc/Solver/Monad.hs index 6666758226..7eb1df9649 100644 --- a/compiler/GHC/Tc/Solver/Monad.hs +++ b/compiler/GHC/Tc/Solver/Monad.hs @@ -902,7 +902,7 @@ runTcS tcs ; ev_binds <- TcM.getTcEvBindsMap ev_binds_var ; return (res, ev_binds) } --- | This variant of 'runTcS' will immediatley fail upon encountering an +-- | This variant of 'runTcS' will immediately fail upon encountering an -- insoluble ct. See Note [Speeding up valid hole-fits]. Its one usage -- site does not need the ev_binds, so we do not return them. runTcSEarlyAbort :: TcS a -> TcM a diff --git a/compiler/GHC/Tc/TyCl.hs b/compiler/GHC/Tc/TyCl.hs index 3e9fa96e39..00cfe6d02b 100644 --- a/compiler/GHC/Tc/TyCl.hs +++ b/compiler/GHC/Tc/TyCl.hs @@ -388,7 +388,7 @@ Open type families This treatment of type synonyms only applies to Haskell 98-style synonyms. General type functions can be recursive, and hence, appear in `alg_decls'. -The kind of an open type family is solely determinded by its kind signature; +The kind of an open type family is solely determined by its kind signature; hence, only kind signatures participate in the construction of the initial kind environment (as constructed by `inferInitialKind'). In fact, we ignore instances of families altogether in the following. However, we need to include @@ -645,7 +645,7 @@ Unfortunately this requires reworking a bit of the code in Note [Don't process associated types in getInitialKind] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously, we processed associated types in the thing_inside in getInitialKind, -but this was wrong -- we want to do ATs sepearately. +but this was wrong -- we want to do ATs separately. The consequence for not doing it this way is #15142: class ListTuple (tuple :: Type) (as :: [(k, Type)]) where @@ -985,7 +985,7 @@ following order: 1. Inferred variables 2. Specified variables; in the left-to-right order in which the user wrote them, modified by scopedSort (see below) - to put them in depdendency order. + to put them in dependency order. 3. Required variables before a top-level :: 4. All variables after a top-level :: @@ -1054,7 +1054,7 @@ Design alternatives ~~~~~~~~~~~~~~~~~~~ * For associated types we considered putting the class variables before the local variables, in a nod to the treatment for class - methods. But it got too compilicated; see #15592, comment:21ff. + methods. But it got too complicated; see #15592, comment:21ff. * We rigidly require the ordering above, even though we could be much more permissive. Relevant musings are at @@ -1820,7 +1820,7 @@ However, during tcTyClDecl of T (above) we will be in a recursive "knot". So we aren't allowed to look at the TyCon T itself; we are only allowed to put it (lazily) in the returned structures. But when kind-checking the RHS of T's decl, we *do* need to know T's kind (so -that we can correctly elaboarate (T k f a). How can we get T's kind +that we can correctly elaborate (T k f a). How can we get T's kind without looking at T? Delicate answer: during tcTyClDecl, we extend *Global* env with T -> ATyCon (the (not yet built) final TyCon for T) @@ -2314,7 +2314,7 @@ In the frontend, the following tweaks have been made in the typechecker: data family F a :: UnliftedType data instance F Int = TInt - The ommission of a kind signature for `F` should not mean a result kind + The omission of a kind signature for `F` should not mean a result kind of `Type` (and thus a kind error) here. * STEP 2: No change to kcTyClDecl. @@ -3085,7 +3085,7 @@ The wildcards are particularly awkward: they may need to be quantified So, we use bindOuterFamEqnTKBndrs (which does not create an implication for the telescope), and generalise over /all/ the variables in the LHS, -without treating the explicitly-quantifed ones specially. Wrinkles: +without treating the explicitly-quantified ones specially. Wrinkles: - When generalising, include the explicit user-specified forall'd variables, so that we get an error from Validity.checkFamPatBinders diff --git a/compiler/GHC/Tc/TyCl/Class.hs b/compiler/GHC/Tc/TyCl/Class.hs index 57f8f19e82..4cb0e9d2c0 100644 --- a/compiler/GHC/Tc/TyCl/Class.hs +++ b/compiler/GHC/Tc/TyCl/Class.hs @@ -99,7 +99,7 @@ generates newtype CDict a = CDict (forall b. a -> b -> b) -Now DictTy in Type is just a form of type synomym: +Now DictTy in Type is just a form of type synonym: DictTy c t = TyConTy CDict `AppTy` t Death to "ExpandingDicts". diff --git a/compiler/GHC/Tc/TyCl/Instance.hs b/compiler/GHC/Tc/TyCl/Instance.hs index 72081727be..86b8626d50 100644 --- a/compiler/GHC/Tc/TyCl/Instance.hs +++ b/compiler/GHC/Tc/TyCl/Instance.hs @@ -1099,7 +1099,7 @@ however, so this Note aims to describe these subtleties: Now the subtleties of Note [Newtype eta and homogeneous axioms] are dealt with by the newtype (via mkNewTyConRhs called in tcDataFamInstDecl) while the axiom connecting F Int ~ R:FIntb is eta-reduced, but the - quantifer 'b' is derived from the original data family F, and so the + quantifier 'b' is derived from the original data family F, and so the kinds will always match. Note [Kind inference for data family instances] @@ -2050,7 +2050,7 @@ The instance signature can be *more* polymorphic than the instantiated class method (in this case: Age -> Age -> Bool), but it cannot be less polymorphic. Moreover, if a signature is given, the implementation code should match the signature, and type variables bound in the -singature should scope over the method body. +signature should scope over the method body. We achieve this by building a TcSigInfo for the method, whether or not there is an instance method signature, and using that to typecheck diff --git a/compiler/GHC/Tc/TyCl/PatSyn.hs b/compiler/GHC/Tc/TyCl/PatSyn.hs index bb142f080a..2e9b3c1809 100644 --- a/compiler/GHC/Tc/TyCl/PatSyn.hs +++ b/compiler/GHC/Tc/TyCl/PatSyn.hs @@ -126,7 +126,7 @@ We stop if there are /any/ unsolved constraints, not just insoluble ones; because pattern synonyms are top-level things, we will never solve them later if we can't solve them now. And if we were to carry on, tc_patsyn_finish does zonkTcTypeToType, which defaults any -unsolved unificatdion variables to Any, which confuses the error +unsolved unification variables to Any, which confuses the error reporting no end (#15685). So we use simplifyTop to completely solve the constraint, report @@ -276,7 +276,7 @@ But neither is 's' itself existentially bound, so the forall (s::k->*) can't go in the inner forall either. (What would the matcher apply the continuation to?) -Solution: do not quantiify over any unification variable whose kind +Solution: do not quantify over any unification variable whose kind mentions the existentials. We can conveniently do that by making the "taus" passed to simplifyInfer look like forall ex_tvs. arg_ty @@ -326,7 +326,7 @@ and that is bad because (a ~# Maybe b) is not a predicate type and is not implicitly instantiated. So in mkProvEvidence we lift (a ~# b) to (a ~ b). Tiresome, and -marginally less efficient, if the builder/martcher are not inlined. +marginally less efficient, if the builder/matcher are not inlined. See also Note [Lift equality constraints when quantifying] in GHC.Tc.Solver diff --git a/compiler/GHC/Tc/TyCl/Utils.hs b/compiler/GHC/Tc/TyCl/Utils.hs index 26a28e7296..e071a7c7a2 100644 --- a/compiler/GHC/Tc/TyCl/Utils.hs +++ b/compiler/GHC/Tc/TyCl/Utils.hs @@ -172,7 +172,7 @@ newtype SynCycleM a = SynCycleM { -- TODO: TyConSet is implemented as IntMap over uniques. -- But we could get away with something based on IntSet --- since we only check membershib, but never extract the +-- since we only check membership, but never extract the -- elements. type SynCycleState = TyConSet diff --git a/compiler/GHC/Tc/Types.hs b/compiler/GHC/Tc/Types.hs index 577fc4407c..5c58a73701 100644 --- a/compiler/GHC/Tc/Types.hs +++ b/compiler/GHC/Tc/Types.hs @@ -184,7 +184,7 @@ import GHC.Linker.Types -- 'ns_module_name' @A@, defines a mapping from @{A.T}@ -- (for some 'OccName' @T@) to some arbitrary other 'Name'. -- --- The most intruiging thing about a 'NameShape', however, is +-- The most intriguing thing about a 'NameShape', however, is -- how it's constructed. A 'NameShape' is *implied* by the -- exported 'AvailInfo's of the implementor of an interface: -- if an implementor of signature @\<H>@ exports @M.T@, you implicitly @@ -401,7 +401,7 @@ data FrontendResult -- signatures (we just generate blank object files for -- hsig files.) -- --- A corrolary of this is that the following invariant holds at any point +-- A corollary of this is that the following invariant holds at any point -- past desugaring, -- -- if I have a Module, this_mod, in hand representing the module @@ -1138,7 +1138,7 @@ data TcTyThing | ATyVar Name TcTyVar -- See Note [Type variables in the type environment] | ATcTyCon TyCon -- Used temporarily, during kind checking, for the - -- tycons and clases in this recursive group + -- tycons and classes in this recursive group -- The TyCon is always a TcTyCon. Its kind -- can be a mono-kind or a poly-kind; in TcTyClsDcls see -- Note [Type checking recursive type and class declarations] diff --git a/compiler/GHC/Tc/Types/Constraint.hs b/compiler/GHC/Tc/Types/Constraint.hs index ed05f8a1de..586a6a68aa 100644 --- a/compiler/GHC/Tc/Types/Constraint.hs +++ b/compiler/GHC/Tc/Types/Constraint.hs @@ -1404,7 +1404,7 @@ The GivenEqs data type describes the Given constraints of an implication constra * LocalGivenEqs: definitely no Given equalities that would affect principal types. But may have equalities that affect only skolems of this implication - (and hence do not affect princial types) + (and hence do not affect principal types) Examples: forall a. F a ~ Int => ... forall a b. F a ~ G b => ... @@ -1557,7 +1557,7 @@ Note [Shadowing in a constraint] We assume NO SHADOWING in a constraint. Specifically * The unification variables are all implicitly quantified at top level, and are all unique - * The skolem variables bound in ic_skols are all freah when the + * The skolem variables bound in ic_skols are all fresh when the implication is created. So we can safely substitute. For example, if we have forall a. a~Int => ...(forall b. ...a...)... @@ -2248,7 +2248,7 @@ equality simplification, and type family reduction. (Why combine these? Because it's actually quite easy to mistake one for another, in sufficiently involved scenarios, like ConstraintKinds.) -The flag -freduction-depth=n fixes the maximium level. +The flag -freduction-depth=n fixes the maximum level. * The counter includes the depth of type class instance declarations. Example: [W] d{7} : Eq [Int] diff --git a/compiler/GHC/Tc/Types/Evidence.hs b/compiler/GHC/Tc/Types/Evidence.hs index 42704013a7..82e7847b02 100644 --- a/compiler/GHC/Tc/Types/Evidence.hs +++ b/compiler/GHC/Tc/Types/Evidence.hs @@ -448,7 +448,7 @@ instance Data.Data TcEvBinds where Class constraints etc give rise to /term/ bindings for evidence, and we have nowhere to put term bindings in /types/. So in some places we use CoEvBindsVar (see newCoTcEvBinds) to signal that no term-level -evidence bindings are allowed. Notebly (): +evidence bindings are allowed. Notably (): - Places in types where we are solving kind constraints (all of which are equalities); see solveEqualities diff --git a/compiler/GHC/Tc/Types/Origin.hs b/compiler/GHC/Tc/Types/Origin.hs index 94801fb0df..7d257f4763 100644 --- a/compiler/GHC/Tc/Types/Origin.hs +++ b/compiler/GHC/Tc/Types/Origin.hs @@ -267,7 +267,7 @@ data SkolemInfoAnon | RuleSkol RuleName -- The LHS of a RULE | InferSkol [(Name,TcType)] - -- We have inferred a type for these (mutually-recursivive) + -- We have inferred a type for these (mutually recursive) -- polymorphic Ids, and are now checking that their RHS -- constraints are satisfied. @@ -1056,7 +1056,7 @@ data FixedRuntimeRepContext -- Test cases: RepPolyDoBody{1,2}, RepPolyMcBody. | FRRBodyStmt !StmtOrigin !Int - -- | Arguments to a guard in a monad comprehesion must have + -- | Arguments to a guard in a monad comprehension must have -- a fixed runtime representation. -- -- Test case: RepPolyMcGuard. diff --git a/compiler/GHC/Tc/Utils/Instantiate.hs b/compiler/GHC/Tc/Utils/Instantiate.hs index 4497fe4d4b..1d47b9610e 100644 --- a/compiler/GHC/Tc/Utils/Instantiate.hs +++ b/compiler/GHC/Tc/Utils/Instantiate.hs @@ -247,7 +247,7 @@ instTyVarsWith :: CtOrigin -> [TyVar] -> [TcType] -> TcM Subst -- types [ta, tb, tc], but when the kinds of 'a' and 'ta' might -- not yet match (perhaps because there are unsolved constraints; #14154) -- If they don't match, emit a kind-equality to promise that they will --- eventually do so, and thus make a kind-homongeneous substitution. +-- eventually do so, and thus make a kind-homogeneous substitution. instTyVarsWith orig tvs tys = go emptySubst tvs tys where @@ -669,7 +669,7 @@ Then we have to instantiate the kind variables, build a substitution from old variables to the new variables, then instantiate the type variables substituting the original kind. -Exemple: If we want to instantiate +Example: If we want to instantiate [(k1 :: *), (k2 :: *), (a :: k1 -> k2), (b :: k1)] we want [(?k1 :: *), (?k2 :: *), (?a :: ?k1 -> ?k2), (?b :: ?k1)] diff --git a/compiler/GHC/Tc/Utils/Monad.hs b/compiler/GHC/Tc/Utils/Monad.hs index 571e02c7cf..346b1f4273 100644 --- a/compiler/GHC/Tc/Utils/Monad.hs +++ b/compiler/GHC/Tc/Utils/Monad.hs @@ -1191,7 +1191,7 @@ is applied to four arguments. See #18379 for a concrete example. This reliance on delicate inlining and Called Arity is not good. See #18202 for a more general approach. But meanwhile, these -ininings seem unobjectional, and they solve the immediate +inlinings seem unobjectional, and they solve the immediate problem. Note [Error contexts in generated code] @@ -1970,7 +1970,7 @@ We must not discard the out-of-scope error. It's distressingly delicate though: * If we discard too /many/ constraints we may fail to report the error - that led us to interrupte the constraint gathering process. + that led us to interrupt the constraint gathering process. One particular example "variable out of scope" Hole constraints. For example (#12529): diff --git a/compiler/GHC/Tc/Utils/TcMType.hs b/compiler/GHC/Tc/Utils/TcMType.hs index 19f368ba99..1cb4820745 100644 --- a/compiler/GHC/Tc/Utils/TcMType.hs +++ b/compiler/GHC/Tc/Utils/TcMType.hs @@ -614,7 +614,7 @@ ensureMonoType :: TcType -> TcM () -- Assuming that the argument type is of kind (TYPE r), -- ensure that it is a /monotype/ -- If it is not a monotype we can see right away (since unification --- varibles and type-function applications stand for monotypes), but +-- variables and type-function applications stand for monotypes), but -- we emit a Wanted equality just to delay the error message until later ensureMonoType res_ty | isTauTy res_ty -- isTauTy doesn't need zonking or anything @@ -1969,7 +1969,7 @@ What do do? D. We could error. We choose (D), as described in #17567, and implement this choice in -doNotQuantifyTyVars. Dicsussion of alternativs A-C is below. +doNotQuantifyTyVars. Discussion of alternativs A-C is below. NB: this is all rather similar to, but sadly not the same as Note [Naughty quantification candidates] diff --git a/compiler/GHC/Tc/Utils/TcType.hs b/compiler/GHC/Tc/Utils/TcType.hs index 240cfb9ef1..6592912d05 100644 --- a/compiler/GHC/Tc/Utils/TcType.hs +++ b/compiler/GHC/Tc/Utils/TcType.hs @@ -329,7 +329,7 @@ so they behave as global constants. Specifically: of Var.Var. The "tc" prefix means "a type variable that can be encountered by the typechecker". -This is a bit of a change from an earlier era when we remoselessly +This is a bit of a change from an earlier era when we remorselessly insisted on real TcTyVars in the type checker. But that seems unnecessary (for skolems, TyVars are fine) and it's now very hard to guarantee, with the advent of kind equalities. @@ -584,7 +584,7 @@ constraint solver. It's not strictly essential, and indeed (historically but still there) Var.tcTyVarDetails returns vanillaSkolemTv for a TyVar. -But ultimately I want to seeparate Type from TcType, and in that case +But ultimately I want to separate Type from TcType, and in that case we would need to enforce the separation. -} @@ -765,7 +765,7 @@ the constraint (C alpha[3]) disobeys WantedInv: (forall[3] b. alpha[3] ~ b) We can unify alpha:=b in the inner implication, because 'alpha' is -touchable; but then 'b' has excaped its scope into the outer implication. +touchable; but then 'b' has escaped its scope into the outer implication. -} maxTcLevel :: TcLevel -> TcLevel -> TcLevel @@ -1901,7 +1901,7 @@ boxEqPred eq_rel ty1 ty2 NomEq | homo_kind -> Just (eqClass, [k1, ty1, ty2]) | otherwise -> Just (heqClass, [k1, k2, ty1, ty2]) ReprEq | homo_kind -> Just (coercibleClass, [k1, ty1, ty2]) - | otherwise -> Nothing -- Sigh: we do not have hererogeneous Coercible + | otherwise -> Nothing -- Sigh: we do not have heterogeneous Coercible -- so we can't abstract over it -- Nothing fundamental: we could add it where diff --git a/compiler/GHC/Tc/Utils/Unify.hs b/compiler/GHC/Tc/Utils/Unify.hs index 1eb81d8191..af71c50156 100644 --- a/compiler/GHC/Tc/Utils/Unify.hs +++ b/compiler/GHC/Tc/Utils/Unify.hs @@ -205,7 +205,7 @@ Ugh! -- | Like 'matchExpectedFunTys', but used when you have an "actual" type, -- for example in function application. -- --- INVARIANT: the returned arguemnt types all have a syntactically fixed RuntimeRep +-- INVARIANT: the returned argument types all have a syntactically fixed RuntimeRep -- in the sense of Note [Fixed RuntimeRep] in GHC.Tc.Utils.Concrete. -- See Note [Return arguments with a fixed RuntimeRep]. matchActualFunTysRho :: ExpectedFunTyOrigin -- ^ See Note [Herald for matchExpectedFunTys] @@ -721,7 +721,7 @@ There is one wrinkle. Suppose we have case e of T1 -> e1 :: (forall a. a->a) -> Int G2 -> e2 -where T1 is not GADT or existential, but G2 is a GADT. Then supppose the +where T1 is not GADT or existential, but G2 is a GADT. Then suppose the T1 alternative fills the hole with (forall a. a->a) -> Int, which is fine. But now the G2 alternative must not *just* unify with that else we'd risk allowing through (e2 :: (forall a. a->a) -> Int). If we'd checked G2 first @@ -2219,7 +2219,7 @@ There are five reasons not to unify: assumptions", section 2.2. We say that alpha[1] is "untouchable" inside this implication. - Bottom line: at amibient level 'l', when looking at a constraint + Bottom line: at ambient level 'l', when looking at a constraint alpha[n] ~ ty, do not unify alpha := ty if there are any given equalities between levels 'n' and 'l'. @@ -2261,7 +2261,7 @@ There are five reasons not to unify: is sensible, but it can lead to very confusing error messages. It's very much like a Wanted rewriting a Wanted. Even worse, unifying a variable essentially turns an equality into a Given, - and so we could not use the tracking mechansim in + and so we could not use the tracking mechanism in Note [Wanteds rewrite Wanteds] in GHC.Tc.Types.Constraint. We thus simply do not unify in this case. diff --git a/compiler/GHC/Tc/Validity.hs b/compiler/GHC/Tc/Validity.hs index b5879940b0..3fbe32352b 100644 --- a/compiler/GHC/Tc/Validity.hs +++ b/compiler/GHC/Tc/Validity.hs @@ -362,7 +362,7 @@ This might not necessarily show up in kind checking. checkValidType :: UserTypeCtxt -> Type -> TcM () -- Checks that a user-written type is valid for the given context -- Assumes argument is fully zonked --- Assumes arugment is well-kinded; +-- Assumes argument is well-kinded; -- that is, checkValidType doesn't need to do kind checking -- Not used for instance decls; checkValidInstance instead checkValidType ctxt ty @@ -1379,7 +1379,7 @@ entirely different meaning. To illustrate, suppose in M.hsig we see instance KnownNat T That says that any module satisfying M.hsig must provide a KnownNat -instance for T. We absolultely need that instance when compiling a +instance for T. We absolutely need that instance when compiling a module that imports M.hsig: see #15379 and Note [Fabricating Evidence for Literals in Backpack] in GHC.Tc.Instance.Class. @@ -2505,7 +2505,7 @@ Note [Printing conflicts with class header] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's remarkably painful to give a decent error message for conflicts with the class header. Consider - clase C b where + class C b where type F a b c instance C [b] where type F x Int _ _ = ... @@ -2557,7 +2557,7 @@ In every case, b is a type variable not determined by the LHS pattern. The first is caught by the renamer, but we catch the last two here. Perhaps one could argue that the second should be accepted, albeit with a warning, but consider the fact that in a type family instance, there is no way to interact -with such a varable. At least with @x :: forall a. Int@ we can use visibile +with such a varable. At least with @x :: forall a. Int@ we can use visible type application, like @x \@Bool 1@. (Of course it does nothing, but it is permissible.) In the type family case, the only sensible explanation is that the user has made a mistake -- thus we throw an error. |