[commit: ghc] master: Typos in comments (e3ab25a)
git at git.haskell.org
git at git.haskell.org
Thu Oct 1 21:22:21 UTC 2015
Repository : ssh://git@git.haskell.org/ghc
On branch : master
Link : http://ghc.haskell.org/trac/ghc/changeset/e3ab25a4d2e159d7c83de7e94252cace2e76d2a1/ghc
>---------------------------------------------------------------
commit e3ab25a4d2e159d7c83de7e94252cace2e76d2a1
Author: Joachim Breitner <mail at joachim-breitner.de>
Date: Thu Oct 1 21:55:57 2015 +0200
Typos in comments
>---------------------------------------------------------------
e3ab25a4d2e159d7c83de7e94252cace2e76d2a1
compiler/simplCore/SimplUtils.hs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/compiler/simplCore/SimplUtils.hs b/compiler/simplCore/SimplUtils.hs
index db74855..effd212 100644
--- a/compiler/simplCore/SimplUtils.hs
+++ b/compiler/simplCore/SimplUtils.hs
@@ -996,14 +996,14 @@ Example
...fInt...fInt...fInt...
-Here f occurs just once, in the RHS of f1. But if we inline it there
+Here f occurs just once, in the RHS of fInt. But if we inline it there
we'll lose the opportunity to inline at each of fInt's call sites.
The INLINE pragma will only inline when the application is saturated
for exactly this reason; and we don't want PreInlineUnconditionally
to second-guess it. A live example is Trac #3736.
c.f. Note [Stable unfoldings and postInlineUnconditionally]
-Note [Top-level botomming Ids]
+Note [Top-level bottoming Ids]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't inline top-level Ids that are bottoming, even if they are used just
once, because FloatOut has gone to some trouble to extract them out.
More information about the ghc-commits
mailing list