summaryrefslogtreecommitdiff
path: root/compiler/iface/BinIface.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove the distinction between data and newtype familiesManuel M T Chakravarty2007-05-111-5/+3
| | | | | | | | | - This patch removes "newtype family" declarations. - "newtype instance" declarations can now be instances of data families - This also fixes bug #1331 ** This patch changes the interface format. All libraries and all of ** ** Stage 2 & 3 need to be re-compiled from scratch. **
* Store a SrcSpan instead of a SrcLoc inside a NameSimon Marlow2007-05-111-1/+1
| | | | This has been a long-standing ToDo.
* IfaceVectInfo and propagation through EPSManuel M T Chakravarty2007-05-041-1/+12
|
* Retain inline-pragma information on unfoldings in interface filessimonpj@microsoft.com2007-04-251-0/+10
| | | | | | | | | | | | | | | | | | | | WARNING: this patch changes interface-file formats slightly you will need to recompile your libraries Duncan Coutts wanted to export a function that has a NOINLNE pragma in a local let-defintion. This works fine within a module, but was not surviving across the interface-file serialisation. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-March/012171.html Regardless of whether or not he's doing something sensible, it seems reasonable to try to retain local-binder IdInfo across interface files. This initial patch just retains inline-pragma info, on the grounds that other IdInfo can be re-inferred at the inline site. Interface files get a tiny bit bigger, but it seesm slight.
* fix version checking of .hi filesSimon Marlow2007-01-081-23/+32
| | | | I broke it during my recent interface-file overhaul
* TickBox representation changeandy@galois.com2006-11-291-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | This changes the internal representation of TickBoxes, from Note (TickBox "module" n) <expr> into case tick<module,n> of _ -> <expr> tick has type :: #State #World, when the module and tick numbe are stored inside IdInfo. Binary tick boxes change from Note (BinaryTickBox "module" t f) <expr> into btick<module,t,f> <expr> btick has type :: Bool -> Bool, with the module and tick number stored inside IdInfo.
* Haskell Program Coverageandy@galois.com2006-10-241-1/+16
| | | | | | | | | | | | | | | | | | | | This large checkin is the new ghc version of Haskell Program Coverage, an expression-level coverage tool for Haskell. Parts: - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files. - Coverage.lhs - Annotates the HsSyn with coverage tickboxes. - New Note's in Core, - TickBox -- ticked on entry to sub-expression - BinaryTickBox -- ticked on exit to sub-expression, depending -- on the boolean result. - New Stg level TickBox (no BinaryTickBoxes, though) You can run the coverage tool with -fhpc at compile time. Main must be compiled with -fhpc.
* Keep track of family instance modulesManuel M T Chakravarty2006-10-131-1/+8
| | | | | | | | | | | | | | - 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-29/+20
| | | | | | | | | | | | 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-53/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+10
| | | | | | | | | | | | | | | | | - 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. ***
* Remove Linear Implicit Parameters, and all their workssimonpj@microsoft.com2006-09-291-18/+3
| | | | | | | Linear implicit parameters have been in GHC quite a while, but we decided they were a mis-feature and scheduled them for removal. This patch does the job.
* Import/export of data constructors in family instancesManuel M T Chakravarty2006-09-201-3/+12
| | | | | | | | | | | | | | | | | | | | | 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! ***
* Introduce coercions for data instance declsManuel M T Chakravarty2006-09-201-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Mon Sep 18 19:07:30 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Introduce coercions for data instance decls Tue Aug 22 20:33:46 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Introduce coercions for data instance decls - data instance declarations implicitly generate a coercion moving between the representation type and family instance type. - The coercion is *implicitly* generated when type checking both source and ifaces. Ie, we don't safe it in ifaces - this is really exactly as newtype coercions are handled. - The previous addition of the instance types to DataCons has been moved to the representation TyCon. This is more efficient as it is shared between all constructors of one representation tycon and it also gathers everything about data instances (family tycon, instance types, and coercion) in one place: the algTcParent field of TyCon. - The coercion is already used in the datacon wrappers, but not yet during type checking pattern matching of indexed data types. - The code has only been lightly tested, but doesn't seem to break features not related to indexed types. For indexed data types only the pattern matching tc code (in TcPat.tcConPat) and some well-formedness checks are still missing. And there will surely be some bugs to fix. (newtypes still require some more work.) ** WARNING: Interface file format changed! ** ** Recompile from scratch! **
* Extend TyCons and DataCons to represent data instance declsManuel M T Chakravarty2006-09-201-5/+8
| | | | | | | | | | | | | | | Mon Sep 18 19:05:18 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extend TyCons and DataCons to represent data instance decls Fri Aug 18 19:11:37 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extend TyCons and DataCons to represent data instance decls - This is a faily involved patch, but it is not entirely complete: + The data con wrapper code for instance data cons needs to apply the coercions (which we still have to generate). + There are still bugs, but it doesn't seem to affect the compilation of code that doesn't use type families. ** WARNING: Yet another change of the iface format. ** ** Recompile everything. **
* Extend Class.Class to include the TyCons of ATsManuel M T Chakravarty2006-09-201-2/+4
| | | | | | | Mon Sep 18 18:58:51 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extend Class.Class to include the TyCons of ATs Wed Aug 16 16:15:31 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extend Class.Class to include the TyCons of ATs
* Extended TyCon and friends to represent family declarationsManuel M T Chakravarty2006-09-201-5/+11
| | | | | | | Mon Sep 18 18:50:35 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extended TyCon and friends to represent family declarations Tue Aug 15 16:52:31 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Extended TyCon and friends to represent family declarations
* Remove argument variance info of tyconsManuel M T Chakravarty2006-09-181-12/+6
| | | | | | | | | | Fri Aug 11 13:53:24 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au> * Remove argument variance info of tycons - Following SPJ's suggestion, this patch removes the variance information from type constructors. This information was computed, but never used. ** WARNING: This patch changes the format of interface files ** ** You will need to rebuild from scratch. **
* Massive patch for the first months work adding System FC to GHC #15Manuel M T Chakravarty2006-08-041-69/+71
| | | | | | | | 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.
* Generalise Package SupportSimon Marlow2006-07-251-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* the unlifted kindSimon Marlow2006-06-231-7/+9
|
* Remove InlinePlease and add inline function and RULEsimonpj@microsoft.com2006-06-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | For a long time GHC has had some internal mechanism designed to support a call-site inline directive, thus inline f xs makes f be inlined at the call site even if f is big. However, the surface syntax seems to have gone, and in any case it can be done more neatly using a RULE. This commit: * Removes the InlineCall constructor for Note and InlinePlease for SimplCont * Adds a new known-key Id called 'inline', whose definition in GHC.Base is just the identity function * Adds a built-in RULE in PrelRules that rewrites (inline f) to the body of f, if possible * Adds documentation NOTE: I have not tested this (aeroplane work). Give it a try!
* Transmit inline pragmas faithfullysimonpj@microsoft.com2006-05-221-8/+11
| | | | | | | | | | | | | | | | | | | | | *** WARNING: you will need to recompile your libraries *** when you pull this patch (make clean; make) The inline pragma on wrapper-functions was being lost; this patch makes it be transmitted faithfully. The reason is that we don't write the full inlining for a wrapper into an interface file, because it's generated algorithmically from its strictness info. But previously the inline pragma as being written out only when we wrote out an unfolding, and hence it was lost for a wrapper. This makes a particular difference when a function has a NOINLINE[k] pragma. Then it may be w/w'd, and we must retain the pragma. It's the only consistent thing to do really. The change does change the binary format of interface files, slightly. So you need to recompile all your libraries.
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+1056
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