Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master
http://hackage.haskell.org/trac/ghc/changeset/1a0af0ece368caf0b6752f05e5e571cd4137ef36 >--------------------------------------------------------------- commit 1a0af0ece368caf0b6752f05e5e571cd4137ef36 Author: Ian Lynagh <i...@well-typed.com> Date: Thu Nov 8 12:27:03 2012 +0000 Add a comment about why we use nextWrapperNum rather than a unique >--------------------------------------------------------------- compiler/typecheck/TcEnv.lhs | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/compiler/typecheck/TcEnv.lhs b/compiler/typecheck/TcEnv.lhs index aa39673..934a9fb 100644 --- a/compiler/typecheck/TcEnv.lhs +++ b/compiler/typecheck/TcEnv.lhs @@ -772,13 +772,25 @@ mkWrapperName :: (MonadIO m, HasDynFlags m, HasModule m) mkWrapperName what nameBase = do dflags <- getDynFlags thisMod <- getModule - let wrapperRef = nextWrapperNum dflags + let -- Note [Generating fresh names for ccall wrapper] + wrapperRef = nextWrapperNum dflags pkg = packageIdString (modulePackageId thisMod) mod = moduleNameString (moduleName thisMod) wrapperNum <- liftIO $ readIORef wrapperRef liftIO $ writeIORef wrapperRef (wrapperNum + 1) let components = [what, show wrapperNum, pkg, mod, nameBase] return $ mkFastString $ zEncodeString $ intercalate ":" components + +{- +Note [Generating fresh names for FFI wrappers] + +We used to use a unique, rather than nextWrapperNum, to distinguish +between FFI wrapper functions. However, the wrapper names that we +generate are external names. This means that if a call to them ends up +in an unfolding, then we can't alpha-rename them, and thus if the +unique randomly changes from one compile to another then we get a +spurious ABI change (#4012). +-} \end{code} %************************************************************************ _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
