extendModuleEnv_C, foldModuleEnv, lookupModuleEnv,
elemModuleSet, extendModuleSet
)
-import PrelInfo ( wiredInThingEnv )
+import PrelInfo ( wiredInThingEnv, hasKey, fractionalClassKey, numClassKey,
+ integerTyConName, doubleTyConName )
import Maybes ( maybeToBool )
import FiniteMap
import Outputable
%* *
%*********************************************************
-mkImportInof figures out what the ``usage information'' for this
+mkImportInfo figures out what the ``usage information'' for this
moudule is; that is, what it must record in its interface file as the
things it uses.
We produce a line for every module B below the module, A, currently being
compiled:
import B <n> ;
-to record the fact that A does import B indireclty. This is used to decide
+to record the fact that A does import B indirectly. This is used to decide
to look to look for B.hi rather than B.hi-boot when compiling a module that
imports A. This line says that A imports B, but uses nothing in it.
So we'll get an early bale-out when compiling A if B's version changes.
+The usage information records:
+
+\begin{itemize}
+\item (a) anything reachable from its body code
+\item (b) any module exported with a @module Foo@
+\item (c) anything reachable from an exported item
+\end{itemize}
+
+Why (b)? Because if @Foo@ changes then this module's export list
+will change, so we must recompile this module at least as far as
+making a new interface file --- but in practice that means complete
+recompilation.
+
+Why (c)? Consider this:
+\begin{verbatim}
+ module A( f, g ) where | module B( f ) where
+ import B( f ) | f = h 3
+ g = ... | h = ...
+\end{verbatim}
+
+Here, @B.f@ isn't used in A. Should we nevertheless record @B.f@ in
+@A@'s usages? Our idea is that we aren't going to touch A.hi if it is
+*identical* to what it was before. If anything about @B.f@ changes
+than anyone who imports @A@ should be recompiled in case they use
+@B.f@ (they'll get an early exit if they don't). So, if anything
+about @B.f@ changes we'd better make sure that something in A.hi
+changes, and the convenient way to do that is to record the version
+number @B.f@ in A.hi in the usage list. If B.f changes that'll force a
+complete recompiation of A, which is overkill but it's the only way to
+write a new, slightly different, A.hi.
+
+But the example is tricker. Even if @B.f@ doesn't change at all,
+@B.h@ may do so, and this change may not be reflected in @f@'s version
+number. But with -O, a module that imports A must be recompiled if
+@B.h@ changes! So A must record a dependency on @B.h@. So we treat
+the occurrence of @B.f@ in the export list *just as if* it were in the
+code of A, and thereby haul in all the stuff reachable from it.
+
+ *** Conclusion: if A mentions B.f in its export list,
+ behave just as if A mentioned B.f in its source code,
+ and slurp in B.f and all its transitive closure ***
+
+[NB: If B was compiled with -O, but A isn't, we should really *still*
+haul in all the unfoldings for B, in case the module that imports A *is*
+compiled with -O. I think this is the case.]
+
\begin{code}
mkImportInfo :: ModuleName -- Name of this module
-> [ImportDecl n] -- The import decls
import_info0 = foldModuleEnv mk_imp_info [] pit
import_info1 = foldModuleEnv mk_imp_info import_info0 hit
- import_info = [ (mod_name, orphans, is_boot, NothingAtAll)
- | (mod_name, (orphans, is_boot)) <- fmToList (iImpModInfo ifaces) ] ++
- import_info1
+ import_info = not_even_opened_imports ++ import_info1
+
+ -- Recall that iImpModInfo describes modules that have been mentioned
+ -- in the import lists of interfaces we have opened, but which we have
+ -- not even opened when compiling this module
+ not_even_opened_imports = [ (mod_name, orphans, is_boot, NothingAtAll)
+ | (mod_name, (orphans, is_boot)) <- fmToList (iImpModInfo ifaces) ]
+
mk_imp_info :: ModIface -> [ImportVersion Name] -> [ImportVersion Name]
mk_imp_info iface so_far
| import_all_mod -- Case (a) and (b); the import-all part
= if is_home_pkg_mod then
go_for_it (Specifically mod_vers (Just export_vers) [] rules_vers)
+ -- Since the module isn't in the mv_map, presumably we
+ -- didn't actually import anything at all from it
else
go_for_it (Everything mod_vers)
-- and the instance decls
-- The outer loop is needed because consider
+ -- instance Foo a => Baz (Maybe a) where ...
+ -- It may be that Baz and Maybe are used in the source module,
+ -- but not Foo; so we need to chase Foo too.
+ --
+ -- We also need to follow superclass refs. In particular, 'chasing Foo' must
+ -- include actually getting in Foo's class decl
+ -- class Wib a => Foo a where ..
+ -- so that its superclasses are discovered. The point is that Wib is a gate too.
+ -- We do this for tycons too, so that we look through type synonyms.
go_outer decls fvs all_gates []
= returnRn (decls, fvs)
(nameSetToList (gates2 `minusNameSet` all_gates))
-- Knock out the all_gates because even if we don't slurp any new
-- decls we can get some apparently-new gates from wired-in names
+ -- and we get an infinite loop
go_inner (decls, fvs, gates) wanted_name
= importDecl wanted_name `thenRn` \ import_result ->
get_gates is_used (IfaceSig {tcdType = ty}) = extractHsTyNames ty
get_gates is_used (ClassDecl { tcdCtxt = ctxt, tcdName = cls, tcdTyVars = tvs, tcdSigs = sigs})
- = (delListFromNameSet (foldr (plusFV . get) (extractHsCtxtTyNames ctxt) sigs)
- (hsTyVarNames tvs)
- `addOneToNameSet` cls)
- `plusFV` implicitGates cls
+ = (super_cls_and_sigs `addOneToNameSet` cls) `unionNameSets`
+ implicitClassGates cls
where
+ super_cls_and_sigs = delListFromNameSet (foldr (plusFV . get) (extractHsCtxtTyNames ctxt) sigs)
+ (hsTyVarNames tvs)
get (ClassOpSig n _ ty _)
| is_used n = extractHsTyNames ty
| otherwise = emptyFVs
| otherwise = emptyFVs
get_bang bty = extractHsTyNames (getBangType bty)
+
+implicitClassGates :: Name -> FreeVars
+implicitClassGates cls
+ -- If we load class Num, add Integer to the free gates
+ -- This takes account of the fact that Integer might be needed for
+ -- defaulting, but we don't want to load Integer (and all its baggage)
+ -- if there's no numeric stuff needed.
+ -- Similarly for class Fractional and Double
+ --
+ -- NB: adding T to the gates will force T to be loaded
+ --
+ -- NB: If we load (say) Floating, we'll end up loading Fractional too,
+ -- since Fractional is a superclass of Floating
+ | cls `hasKey` numClassKey = unitFV integerTyConName
+ | cls `hasKey` fractionalClassKey = unitFV doubleTyConName
+ | otherwise = emptyFVs
\end{code}
@getWiredInGates@ is just like @getGates@, but it sees a previously-loaded
-- mentioned in other modules, and hence are in the type environment
getWiredInGates (AnId the_id) = namesOfType (idType the_id)
-getWiredInGates (AClass cl) = emptyFVs -- The superclasses must also be previously
- -- loaded, and hence are automatically gates
+getWiredInGates (AClass cl) = implicitClassGates (getName cl)
+ -- The superclasses must also be previously
+ -- loaded, and hence are automatically gates
+ -- All previously-loaded classes are automatically gates
+ -- See "The gating story" above
getWiredInGates (ATyCon tc)
| isSynTyCon tc = delListFromNameSet (namesOfType ty) (map getName tyvars)
| otherwise = unitFV (getName tc)
getIfacesRn `thenRn` \ ifaces ->
getTypeEnvRn `thenRn` \ lookup ->
let
- available n = n `elemNameSet` gates
- || case lookup n of { Just (AClass c) -> True; other -> False }
+ available n
+ | n `elemNameSet` gates = True
+ | otherwise = case lookup n of { Just (AClass c) -> True; other -> False }
-- See "The gating story" above for the AClass thing
(decls, new_insts) = selectGated available (iInsts ifaces)
projects / ghc-hetmet.git / blobdiff