diff --git a/compiler/GHC/Tc/Deriv/Generate.hs b/compiler/GHC/Tc/Deriv/Generate.hs index 8177416c4b2fb0f07d59eafdd94cc24807ac08d0..a9791043a2f060081ef1cb9992f977f5a832db4c 100644 --- a/compiler/GHC/Tc/Deriv/Generate.hs +++ b/compiler/GHC/Tc/Deriv/Generate.hs @@ -592,8 +592,8 @@ gen_Enum_binds loc tycon = do [ succ_enum dflags , pred_enum dflags , to_enum dflags - , enum_from dflags - , enum_from_then dflags + , enum_from dflags -- [0 ..] + , enum_from_then dflags -- [0, 1 ..] , from_enum dflags ] aux_binds = listToBag $ map DerivAuxBind diff --git a/compiler/GHC/Types/Name/Occurrence.hs b/compiler/GHC/Types/Name/Occurrence.hs index 6a9967415e453bb45e8db510458cd0296ca760fd..04f81c312939345750ba4d44d9bc910aaf920e87 100644 --- a/compiler/GHC/Types/Name/Occurrence.hs +++ b/compiler/GHC/Types/Name/Occurrence.hs @@ -624,7 +624,7 @@ mkIPOcc = mk_simple_deriv varName "$i" mkSpecOcc = mk_simple_deriv varName "$s" mkForeignExportOcc = mk_simple_deriv varName "$f" mkRepEqOcc = mk_simple_deriv tvName "$r" -- In RULES involving Coercible -mkClassDataConOcc = mk_simple_deriv dataName "C:" -- Data con for a class +mkClassDataConOcc = mk_simple_deriv dataName "C:" -- Data con for a class mkNewTyCoOcc = mk_simple_deriv tcName "N:" -- Coercion for newtypes mkInstTyCoOcc = mk_simple_deriv tcName "D:" -- Coercion for type functions mkEqPredCoOcc = mk_simple_deriv tcName "$co" diff --git a/docs/users_guide/debugging.rst b/docs/users_guide/debugging.rst index fe9a180a4f7e1903d0272f2a136ccbafc6420f00..c777ccc25cfdba639ae2ea4cbe39b9ae75b27bcc 100644 --- a/docs/users_guide/debugging.rst +++ b/docs/users_guide/debugging.rst @@ -301,7 +301,7 @@ subexpression elimination pass. Rules are filtered by the user provided string, a rule is kept if a prefix of its name matches the string. The pass then checks whether any of these rules could apply to - the program but which didn't file for some reason. For example, specifying + the program but which didn't fire for some reason. For example, specifying ``-drule-check=SPEC`` will check whether there are any applications which might be subject to a rule created by specialisation. diff --git a/libraries/base/GHC/List.hs b/libraries/base/GHC/List.hs index 3215f12b5b33aa7753f81111e10fd1cc055ca41c..0af80801ae70e49bf99498d7d5cccd2d283e94d0 100644 --- a/libraries/base/GHC/List.hs +++ b/libraries/base/GHC/List.hs @@ -277,10 +277,10 @@ to list-producing functions abstracted over cons and nil. Here we call them FB functions because their names usually end with 'FB'. It's a good idea to inline FB functions because: -* They are higher-order functions and therefore benefits from inlining. +* They are higher-order functions and therefore benefit from inlining. * When the final consumer is a left fold, inlining the FB functions is the only - way to make arity expansion to happen. See Note [Left fold via right fold]. + way to make arity expansion happen. See Note [Left fold via right fold]. For this reason we mark all FB functions INLINE [0]. The [0] phase-specifier ensures that calls to FB functions can be written back to the original form