[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