summaryrefslogtreecommitdiff
path: root/compiler/iface/LoadIface.lhs
Commit message (Collapse)AuthorAgeFilesLines
...
* make opt_HiVersion an Integer instead of Int to prevent overflowwolfgang.thaller@gmx.net2007-04-141-1/+1
| | | | | | When a snapshot version number is included, opt_HiVersion tends to exceed the range of a 32bit Int. MERGE TO STABLE
* partial fix for #1119Simon Marlow2007-03-271-19/+26
| | | | | | | | | | | | | | | | | | Unless we're in one-shot mode, emit an error if we attempt to demand-load interfaces for home modules. This can only happen in one way (that I'm aware of): typing a qualified name at the GHCi prompt that refers to a module that isn't loaded. Previously you got a cryptic message about not finding an interface file, now you get: Prelude> Foo.a <interactive>:1:0: attempting to use module `Foo' (Foo.hs) which is not loaded Of course you can still refer to package modules like this without loading them explicitly, only home modules are affected, and the behaviour is exactly the same as if you try to ':browse Foo' and Foo isn't loaded.
* Comment out debug tracessimonpj@microsoft.com2007-03-161-1/+1
|
* Fix a nasty recursive loop in typechecking interface filessimonpj@microsoft.com2007-01-111-1/+21
|
* Zap stray whitespace in lhs formattingSamuel Bronson2006-11-101-1/+1
|
* Fix show-iface for family instances & add debug ppr for type declarationsManuel M T Chakravarty2006-10-191-0/+1
|
* Cross-module consistency check for family instancesManuel M T Chakravarty2006-10-181-3/+17
|
* Keep track of family instance modulesManuel M T Chakravarty2006-10-131-5/+12
| | | | | | | | | | | | | | - Now each modules carries (1) a flag saying whether it contains family instance declarations and (2) a list of all modules further down in the import tree that contain family instance declarations. (The information is split into these two parts for the exact same reasons why the info about orphan modules is split, too.) - This is the first step to *optimised* overlap checking of family instances coming from imported modules. *** WARNING: This patch changes the interface file format! *** *** Recompile libraries and stage2 from scratch! ***
* Module header tidyup, phase 1Simon Marlow2006-10-111-46/+31
| | | | | | | | | | | | This patch is a start on removing import lists and generally tidying up the top of each module. In addition to removing import lists: - Change DATA.IOREF -> Data.IORef etc. - Change List -> Data.List etc. - Remove $Id$ - Update copyrights - Re-order imports to put non-GHC imports last - Remove some unused and duplicate imports
* Interface file optimisation and removal of nameParentSimon Marlow2006-10-111-87/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rough matches for family instancesManuel M T Chakravarty2006-10-101-20/+28
| | | | | | | | | | | | | | | | | - 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. ***
* Fix up the typechecking of interface files during --makesimonpj@microsoft.com2006-10-061-21/+17
| | | | | | | | | | | | 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.
* Trim imports, and remove some dead codesimonpj@microsoft.com2006-09-231-2/+1
|
* Remove duplicate call to getDOptssimonpj@microsoft.com2006-09-221-2/+1
|
* Import/export of data constructors in family instancesManuel M T Chakravarty2006-09-201-6/+15
| | | | | | | | | | | | | | | | | | | | | Mon Sep 18 19:50:42 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Import/export of data constructors in family instances Tue Sep 12 13:54:37 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Import/export of data constructors in family instances - Data constructors of a data/newtype family F can be exported and imported by writing F(..) or F(ConName). - This appears the most natural from a user's persepctive - although, it has a slightly different flavour than similar import/exports items for closed data types. The data constructors denoted by F(..) vary in dependence on the visible data instances. - This has been non-trivial to achieve as RnNames derives its knowledge of what sub-binders an F(..) item exports/imports from the relation specified by Name.nameParent - ie, the constructors of a data/newtype instance need to have the family name (not the internal name of the representation tycon) as their parent. *** WARNING: This patched changes the iface format! *** *** Please re-compile from scratch! ***
* Get of fam inst index in ifacesManuel M T Chakravarty2006-09-201-3/+2
| | | | | | | | | | | | | | Mon Sep 18 19:40:42 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Get of fam inst index in ifaces Fri Sep 8 16:31:26 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Get of fam inst index in ifaces - Removes the explicit index to get unique names for derived tycons for family instances again, following a suggestion by SPJ. - We now derive the coercion tycon name from the name of the representation tycon, which is in the iface anyways. *** WARNING: Change of interface file format! *** *** Recompile from scratch! ***
* ATs are now implicitTyThingsManuel M T Chakravarty2006-09-201-12/+4
| | | | | | | Mon Sep 18 19:36:03 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * ATs are now implicitTyThings Tue Sep 5 21:09:54 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * ATs are now implicitTyThings
* Straightened out implicit coercions for indexed typesManuel M T Chakravarty2006-09-201-7/+21
| | | | | | | | | | | | | | | | | | | | | | | Mon Sep 18 19:35:24 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Straightened out implicit coercions for indexed types Mon Sep 4 23:46:14 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Straightened out implicit coercions for indexed types - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now include the coercion of indexed data/newtypes. - Name generation for the internal names of indexed data/newtypes now uses the same counter that generates the dfun unique indexes (ie, class and type instances are counted with the one counter). We could make this two separate counters if that's what's preferred. - The unique index of a data/newtype instances needs to go into the iface, so that we can generate the same names on slurping in the iface as when the original module was generated. This is a bit yucky, but I don't see a way to avoid that (other than putting the full blown internal tycon name and coercion name into the iface, which IMHO would be worse). - The predicate for when a datacon has a wrapper didn't take GADT equations nor whether it comes froma family instance into account. *** WARNING! This patch changed the interface file format. *** *** Please recompile from scratch. ***
* Fixed two bugs concerning faniliesManuel M T Chakravarty2006-09-201-3/+21
| | | | | | | Mon Sep 18 19:34:38 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Fixed two bugs concerning fanilies Mon Sep 4 20:59:49 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Fixed two bugs concerning fanilies
* Flip direction of newtype coercions, fix some commentsManuel M T Chakravarty2006-09-201-2/+1
| | | | | | | | Mon Sep 18 17:19:19 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Flip direction of newtype coercions, fix some comments Sun Aug 6 20:56:23 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Flip direction of newtype coercions, fix some comments Thu Aug 3 10:53:37 EDT 2006 kevind@bu.edu
* Remove mi_package from moved pprModIfaceManuel M T Chakravarty2006-09-201-3/+0
| | | | | Mon Aug 7 12:40:55 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Remove mi_package from moved pprModIface
* Massive patch for the first months work adding System FC to GHC #20Manuel M T Chakravarty2006-09-201-18/+144
| | | | | | | | | | | Fri Aug 4 17:43:25 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Massive patch for the first months work adding System FC to GHC #20 Broken up massive patch -=chak Original log message: This is (sadly) all done in one patch to avoid Darcs bugs. It's not complete work... more FC stuff to come. A compiler using just this patch will fail dismally.
* A class in an interface file defines the CoTyCon of its class tyocnsimonpj@microsoft.com2006-07-131-1/+4
|
* reformat importSimon Marlow2006-09-131-2/+3
|
* minor reformattingSimon Marlow2006-09-131-6/+9
|
* Improve the "could not find module" error messageSimon Marlow2006-08-111-7/+5
| | | | | | In particular, if we're searching for the profiling version of a module in another package, then suggest that perhaps it might not have been installed.
* don't qualify module name for importedSrcLocSimon Marlow2006-08-111-1/+2
|
* Generalise Package SupportSimon Marlow2006-07-251-82/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch pushes through one fundamental change: a module is now identified by the pair of its package and module name, whereas previously it was identified by its module name alone. This means that now a program can contain multiple modules with the same name, as long as they belong to different packages. This is a language change - the Haskell report says nothing about packages, but it is now necessary to understand packages in order to understand GHC's module system. For example, a type T from module M in package P is different from a type T from module M in package Q. Previously this wasn't an issue because there could only be a single module M in the program. The "module restriction" on combining packages has therefore been lifted, and a program can contain multiple versions of the same package. Note that none of the proposed syntax changes have yet been implemented, but the architecture is geared towards supporting import declarations qualified by package name, and that is probably the next step. It is now necessary to specify the package name when compiling a package, using the -package-name flag (which has been un-deprecated). Fortunately Cabal still uses -package-name. Certain packages are "wired in". Currently the wired-in packages are: base, haskell98, template-haskell and rts, and are always referred to by these versionless names. Other packages are referred to with full package IDs (eg. "network-1.0"). This is because the compiler needs to refer to entities in the wired-in packages, and we didn't want to bake the version of these packages into the comiler. It's conceivable that someone might want to upgrade the base package independently of GHC. Internal changes: - There are two module-related types: ModuleName just a FastString, the name of a module Module a pair of a PackageId and ModuleName A mapping from ModuleName can be a UniqFM, but a mapping from Module must be a FiniteMap (we provide it as ModuleEnv). - The "HomeModules" type that was passed around the compiler is now gone, replaced in most cases by the current package name which is contained in DynFlags. We can tell whether a Module comes from the current package by comparing its package name against the current package. - While I was here, I changed PrintUnqual to be a little more useful: it now returns the ModuleName that the identifier should be qualified with according to the current scope, rather than its original module. Also, PrintUnqual tells whether to qualify module names with package names (currently unused). Docs to follow.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+582
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status