[commit: ghc] master: Correct spelling errors (1f924cb)
git at git.haskell.org
git at git.haskell.org
Tue Jul 17 19:35:50 UTC 2018
Repository : ssh://git@git.haskell.org/ghc
On branch : master
Link : http://ghc.haskell.org/trac/ghc/changeset/1f924cb399ea0638356c8e28d8d3593fa63b653f/ghc
>---------------------------------------------------------------
commit 1f924cb399ea0638356c8e28d8d3593fa63b653f
Author: Sasa Bogicevic <t4nt0r at protonmail.com>
Date: Tue Jul 17 21:34:04 2018 +0200
Correct spelling errors
Reviewers: bgamari, osa1
Reviewed By: osa1
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #15408
Differential Revision: https://phabricator.haskell.org/D4978
>---------------------------------------------------------------
1f924cb399ea0638356c8e28d8d3593fa63b653f
compiler/typecheck/TcUnify.hs | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/compiler/typecheck/TcUnify.hs b/compiler/typecheck/TcUnify.hs
index 410277c..31ddf0f 100644
--- a/compiler/typecheck/TcUnify.hs
+++ b/compiler/typecheck/TcUnify.hs
@@ -558,7 +558,7 @@ tcSubTypeET _ _ (Infer inf_res) ty_expected
= ASSERT2( not (ir_inst inf_res), ppr inf_res $$ ppr ty_expected )
-- An (Infer inf_res) ExpSigmaType passed into tcSubTypeET never
-- has the ir_inst field set. Reason: in patterns (which is what
- -- tcSubTypeET is used for) do not agressively instantiate
+ -- tcSubTypeET is used for) do not aggressively instantiate
do { co <- fill_infer_result ty_expected inf_res
-- Since ir_inst is false, we can skip fillInferResult
-- and go straight to fill_infer_result
@@ -750,7 +750,7 @@ tc_sub_type_ds eq_orig inst_orig ctxt ty_actual ty_expected
-- go ty_a (TyVarTy alpha)
-- which, in the impredicative case unified alpha := ty_a
-- where th_a is a polytype. Not only is this probably bogus (we
- -- simply do not have decent story for imprdicative types), but it
+ -- simply do not have decent story for impredicative types), but it
-- caused Trac #12616 because (also bizarrely) 'deriving' code had
-- -XImpredicativeTypes on. I deleted the entire case.
@@ -907,7 +907,7 @@ has the ir_inst flag.
f :: forall {a}. a -> forall b. Num b => b -> b -> b
This is surely confusing for users.
- And worse, the monomorphism restriction won't properly. The MR is
+ And worse, the monomorphism restriction won't work properly. The MR is
dealt with in simplifyInfer, and simplifyInfer has no way of
instantiating. This could perhaps be worked around, but it may be
hard to know even when instantiation should happen.
@@ -1024,7 +1024,7 @@ to
(forall a. a->a) -> alpha[l+1]
and emit the constraint
[W] alpha[l+1] ~ Int
-Now the poromoted type can fill the ref cell, while the emitted
+Now the promoted type can fill the ref cell, while the emitted
equality can float or not, according to the usual rules.
But that's not quite right! We are exposing the arrow! We could
@@ -1037,7 +1037,7 @@ Here we abstract over the '->' inside the forall, in case that
is subject to an equality constraint from a GADT match.
Note that we kept the outer (->) because that's part of
-the polymorphic "shape". And becauuse of impredicativity,
+the polymorphic "shape". And because of impredicativity,
GADT matches can't give equalities that affect polymorphic
shape.
@@ -1662,7 +1662,7 @@ So we look for a positive reason to swap, using a three-step test:
on the left because there are fewer
restrictions on updating TauTvs
- - SigTv/TauTv: put on the left eitehr
+ - SigTv/TauTv: put on the left either
a) Because it's touchable and can be unified, or
b) Even if it's not touchable, TcSimplify.floatEqualities
looks for meta tyvars on the left
@@ -1694,7 +1694,7 @@ Wanteds and Givens, but either way, deepest wins! Simple.
If we orient the Given a[2] on the left, we'll rewrite the Wanted to
(beta[1] ~ b[1]), and that can float out of the implication.
Otherwise it can't. By putting the deepest variable on the left
- we maximise our changes of elminating skolem capture.
+ we maximise our changes of eliminating skolem capture.
See also TcSMonad Note [Let-bound skolems] for another reason
to orient with the deepest skolem on the left.
@@ -1757,7 +1757,7 @@ where fsk is a flatten-skolem (FlatSkolTv). Suppose we have
then we'll reduce the second constraint to
[G] a ~ fsk
and then replace all uses of 'a' with fsk. That's bad because
-in error messages intead of saying 'a' we'll say (F [a]). In all
+in error messages instead of saying 'a' we'll say (F [a]). In all
places, including those where the programmer wrote 'a' in the first
place. Very confusing! See Trac #7862.
@@ -1997,7 +1997,7 @@ matchExpectedFunKind hs_ty = go
Suppose we are considering unifying
(alpha :: *) ~ Int -> (beta :: alpha -> alpha)
This may be an error (what is that alpha doing inside beta's kind?),
-but we must not make the mistake of actuallyy unifying or we'll
+but we must not make the mistake of actually unifying or we'll
build an infinite data structure. So when looking for occurrences
of alpha in the rhs, we must look in the kinds of type variables
that occur there.
More information about the ghc-commits
mailing list