- 11 Oct, 2006 1 commit
-
-
Simon Marlow authored
This large commit combines several interrelated changes: - IfaceSyn now contains actual Names rather than the special IfaceExtName type. The binary interface file contains a symbol table of Names, where each entry is a (package, ModuleName, OccName) triple. Names in the IfaceSyn point to entries in the symbol table. This reduces the size of interface files, which should hopefully improve performance (not measured yet). The toIfaceXXX functions now do not need to pass around a function from Name -> IfaceExtName, which makes that code simpler. - Names now do not point directly to their parents, and the nameParent operation has gone away. It turned out to be hard to keep this information consistent in practice, and the parent info was only valid in some Names. Instead we made the following changes: * ImportAvails contains a new field imp_parent :: NameEnv AvailInfo which gives the family info for any Name in scope, and is used by the renamer when renaming export lists, amongst other things. This info is thrown away after renaming. * The mi_ver_fn field of ModIface now maps to (OccName,Version) instead of just Version, where the OccName is the parent name. This mapping is used when constructing the usage info for dependent modules. There may be entries in mi_ver_fn for things that are not in scope, whereas imp_parent only deals with in-scope things. * The md_exports field of ModDetails now contains [AvailInfo] rather than NameSet. This gives us family info for the exported names of a module. Also: - ifaceDeclSubBinders moved to IfaceSyn (seems like the right place for it). - heavily refactored renaming of import/export lists. - Unfortunately external core is now broken, as it relied on IfaceSyn. It requires some attention.
-
- 10 Oct, 2006 9 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
See test rn003
-
Simon Marlow authored
Avoid possibility of name clash
-
Ian Lynagh authored
-
chak@cse.unsw.edu.au. authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Fixes Trac #925 A new comment in TcRnDriver in tcRnStmt reads thus: At one stage I removed any shadowed bindings from the type_env; they are inaccessible but might, I suppose, cause a space leak if we leave them there. However, with Template Haskell they aren't necessarily inaccessible. Consider this GHCi session Prelude> let f n = n * 2 :: Int Prelude> fName <- runQ [| f |] Prelude> $(return $ AppE fName (LitE (IntegerL 7))) 14 Prelude> let f n = n * 3 :: Int Prelude> $(return $ AppE fName (LitE (IntegerL 7))) In the last line we use 'fName', which resolves to the *first* 'f' in scope. If we delete it from the type env, GHCi crashes because it doesn't expect that.
-
simonpj@microsoft.com authored
-
chak@cse.unsw.edu.au. authored
- Class and type family instances just got a lot more similar. - FamInst, like Instance, now has a rough match signature. The idea is the same: if the rough match doesn't match, there is no need to pull in the while tycon describing the instance (from a lazily read iface). - IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is now written into the binary iface (as for class instances), as deriving it from the tycon (as before) would render the whole rough matching useless. - As a result of this, the plumbing of class instances and type instances through the various environments, ModIface, ModGuts, and ModDetails is now almost the same. (The remaining difference are mostly because the dfun of a class instance is an Id, but type instance refer to a TyCon, not an Id.) *** WARNING: The interface file format changed! *** *** Rebuild from scratch. ***
-
- 09 Oct, 2006 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 07 Oct, 2006 1 commit
-
-
tharris@microsoft.com authored
-
- 04 Oct, 2006 1 commit
-
-
Ian Lynagh authored
-
- 06 Oct, 2006 12 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Mention that the module sub-directory structure for .o and .hi files is created automatically by GHC
-
simonpj@microsoft.com authored
With the new Haddock patch, renamer errors can be duplicated; so we want to bale out before doing the Haddock stuff if errors are found. (E.g test mod67 shows this up.)
-
simonpj@microsoft.com authored
This patch changes HscTypes.lookupIfaceByModule. The problem was that when compiling the 'base' package, we'd repeatedly reload GHC.Prim. This is easily fixed by looking in the PIT too. A comment with lookupIfaceByModule explains
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
This patch fixes Trac #909. The problem was that when compiling the base package, the handling of wired-in things wasn't right; in TcIface.tcWiredInTyCon it repeatedly loaded GHC.Base.hi into the PIT, even though that was the very module it was compiling. The main fix is by introducing TcIface.ifCheckWiredInThing. But I did some minor refactoring as well.
-
simonpj@microsoft.com authored
-
Simon Marlow authored
This is a slight improvement over the patch sent by jamey@minilop.net, we now do it properly if the source repo was a GHC tree on the local filesystem too. Merge post 6.6.
-
simonpj@microsoft.com authored
Comment Note [Take care] explains. mkAtomicArgs is a mess. A substantial rewrite of Simplify is needed.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
- 05 Oct, 2006 1 commit
-
-
davve@dtek.chalmers.se authored
-
- 29 Sep, 2006 1 commit
-
-
brianlsmith@gmail.com authored
-
- 05 Oct, 2006 2 commits
-
-
simonpj@microsoft.com authored
-
Ian Lynagh authored
-
- 03 Oct, 2006 6 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 05 Oct, 2006 4 commits
-
-
Ian Lynagh authored
-
simonpj@microsoft.com authored
This patch teaches SpecConstr about casts; see Note [SpecConstr for casts]
-
simonpj@microsoft.com authored
Note [Float coercions] ~~~~~~~~~~~~~~~~~~~~~~ When we find the binding x = e `cast` co we'd like to transform it to x' = e x = x `cast` co -- A trivial binding There's a chance that e will be a constructor application or function, or something like that, so moving the coerion to the usage site may well cancel the coersions and lead to further optimisation. Example: data family T a :: * data instance T Int = T Int foo :: Int -> Int -> Int foo m n = ... where x = T m go 0 = 0 go n = case x of { T m -> go (n-m) } -- This case should optimise
-
simonpj@microsoft.com authored
-