summaryrefslogtreecommitdiff
path: root/compiler/prelude/TysWiredIn.lhs
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove dead codesimonpj@microsoft.com2010-09-031-10/+0
|
* Fix Trac #3966: warn about useless UNPACK pragmassimonpj@microsoft.com2010-05-061-3/+2
| | | | | | | | | | | | Warning about useless UNPACK pragmas wasn't as easy as I thought. I did quite a bit of refactoring, which improved the code by refining the types somewhat. In particular notice that in DataCon, we have dcStrictMarks :: [HsBang] dcRepStrictness :: [StrictnessMarks] The former relates to the *source-code* annotation, the latter to GHC's representation choice.
* Minor refactoringsimonpj@microsoft.com2009-10-301-1/+5
| | | | MkCore.mkCoreTupTy moves to TysWiredIn, where it is called mkBoxedTupleTy
* Remove a redundant parameter for mkTupleTy (the arity)simonpj@microsoft.com2009-10-281-3/+5
|
* Fix Trac #959: a long-standing bug in instantiating otherwise-unbound type ↵simonpj@microsoft.com2009-10-151-4/+2
| | | | | | | | | | | | | | | | | | | | | | | variables DO NOT MERGE TO GHC 6.12 branch (Reason: interface file format change.) The typechecker needs to instantiate otherwise-unconstraint type variables to an appropriately-kinded constant type, but we didn't have a supply of arbitrarily-kinded tycons for this purpose. Now we do. The details are described in Note [Any types] in TysPrim. The fundamental change is that there is a new sort of TyCon, namely AnyTyCon, defined in TyCon. Ter's a small change to interface-file binary format, because the new AnyTyCons have to be serialised. I tided up the handling of uniques a bit too, so that mkUnique is not exported, so that we can see all the different name spaces in one module.
* Remove GHC's haskell98 dependencyIan Lynagh2009-07-241-1/+1
|
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-2/+0
|
* Make record selectors into ordinary functionssimonpj@microsoft.com2009-01-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This biggish patch addresses Trac #2670. The main effect is to make record selectors into ordinary functions, whose unfoldings appear in interface files, in contrast to their previous existence as magic "implicit Ids". This means that the usual machinery of optimisation, analysis, and inlining applies to them, which was failing before when the selector was somewhat complicated. (Which it can be when strictness annotations, unboxing annotations, and GADTs are involved.) The change involves the following points * Changes in Var.lhs to the representation of Var. Now a LocalId can have an IdDetails as well as a GlobalId. In particular, the information that an Id is a record selector is kept in the IdDetails. While compiling the current module, the record selector *must* be a LocalId, so that it participates properly in compilation (free variables etc). This led me to change the (hidden) representation of Var, so that there is now only one constructor for Id, not two. * The IdDetails is persisted into interface files, so that an importing module can see which Ids are records selectors. * In TcTyClDecls, we generate the record-selector bindings in renamed, but not typechecked form. In this way, we can get the typechecker to add all the types and so on, which is jolly helpful especially when GADTs or type families are involved. Just like derived instance declarations. This is the big new chunk of 180 lines of code (much of which is commentary). A call to the same function, mkAuxBinds, is needed in TcInstDcls for associated types. * The typechecker therefore has to pin the correct IdDetails on to the record selector, when it typechecks it. There was a neat way to do this, by adding a new sort of signature to HsBinds.Sig, namely IdSig. This contains an Id (with the correct Name, Type, and IdDetails); the type checker uses it as the binder for the final binding. This worked out rather easily. * Record selectors are no longer "implicit ids", which entails changes to IfaceSyn.ifaceDeclSubBndrs HscTypes.implicitTyThings TidyPgm.getImplicitBinds (These three functions must agree.) * MkId.mkRecordSelectorId is deleted entirely, some 300+ lines (incl comments) of very error prone code. Happy days. * A TyCon no longer contains the list of record selectors: algTcSelIds is gone The renamer is unaffected, including the way that import and export of record selectors is handled. Other small things * IfaceSyn.ifaceDeclSubBndrs had a fragile test for whether a data constructor had a wrapper. I've replaced that with an explicit flag in the interface file. More robust I hope. * I renamed isIdVar to isId, which touched a few otherwise-unrelated files.
* Allow type families to use GADT syntax (and be GADTs)simonpj@microsoft.com2008-09-231-1/+2
| | | | | | | | | | | | | | We've always intended to allow you to use GADT syntax for data families: data instance T [a] where T1 :: a -> T [a] and indeed to allow data instances to *be* GADTs data intsance T [a] where T1 :: Int -> T [Int] T2 :: a -> b -> T [(a,b)] This patch fixes the renamer and type checker to allow this.
* Add ASSERTs to all calls of nameModulesimonpj@microsoft.com2008-10-031-3/+5
| | | | | | nameModule fails on an InternalName. These ASSERTS tell you which call failed.
* Document TysWiredIn and follow OccName changesMax Bolingbroke2008-07-311-25/+27
|
* Move Int, Float and Double into ghc-prim:GHC.TypesIan Lynagh2008-08-061-6/+6
|
* Move the Char datatype into ghc-primIan Lynagh2008-08-051-2/+2
|
* Move the [] definion from base to ghc-primIan Lynagh2008-08-051-3/+3
|
* Add 123## literals for Word#Ian Lynagh2008-04-231-0/+12
|
* TysWiredIn is now warning-freeIan Lynagh2008-04-131-24/+61
|
* (F)SLIT -> (f)sLit in TysWiredInIan Lynagh2008-04-121-20/+18
|
* Follow library changesIan Lynagh2008-03-231-3/+3
| | | | | Integer, Bool and Unit/Inl/Inr are now in new packages integer and ghc-prim.
* Fix CodingStyle#Warnings URLsIan Lynagh2007-09-041-1/+1
|
* Use OPTIONS rather than OPTIONS_GHC for pragmasIan Lynagh2007-09-031-2/+2
| | | | | | | Older GHCs can't parse OPTIONS_GHC. This also changes the URL referenced for the -w options from WorkingConventions#Warnings to CodingStyle#Warnings for the compiler modules.
* Add {-# OPTIONS_GHC -w #-} and some blurb to all compiler modulesIan Lynagh2007-09-011-0/+7
|
* Generating synonym instance representation tyconsManuel M T Chakravarty2007-04-251-1/+1
| | | | | | | | - Type synonym instances are turned into representation synonym tycons - They are entered into the pool of family instances (FamInst environments) in the same way as data/newtype instances - Still missing is writing the parent tycon information into ifaces and various well-formedness checks.
* Retrieving the datacon of an arbitrary closurePepe Iborra2006-12-101-0/+2
| | | | | | | | | | | This patch extends the RTS linker and the dynamic linker so that it is possible to find out the datacon of a closure in heap at runtime: - The RTS linker now carries a hashtable 'Address->Symbol' for data constructors - The Persistent Linker State in the dynamic linker is extended in a similar way. Finally, these two sources of information are consulted by: > Linker.recoverDataCon :: a -> TcM Name
* Cosmetics onlysimonpj@microsoft.com2006-11-101-1/+1
|
* Add the primitive type Any, and use it for Dynamicssimonpj@microsoft.com2006-10-181-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC's code generator can only enter a closure if it's guaranteed not to be a function. In the Dynamic module, we were using the type (forall a.a) as the type to which the dynamic type was unsafely cast: type Obj = forall a.a Gut alas this polytype was sometimes instantiated to (), something like this (it only bit when profiling was enabled) let y::() = dyn () in (y `cast` ..) p q As a result, an ASSERT in ClosureInfo fired (hooray). I've tided this up by making a new, primitive, lifted type Any, and arranging that Dynamic uses Any, thus: type Obj = ANy While I was at it, I also arranged that when the type checker instantiates un-constrained type variables, it now instantiates them to Any, not () e.g. length Any [] [There remains a Horrible Hack when we want Any-like things at arbitrary kinds. This essentially never happens, but see comments with TysPrim.mkAnyPrimTyCon.] Anyway, this fixes Trac #905
* Interface file optimisation and removal of nameParentSimon Marlow2006-10-111-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Introduce coercions for data instance declsManuel M T Chakravarty2006-09-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+4
| | | | | | | | | | | | | | | 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. **
* Remove argument variance info of tyconsManuel M T Chakravarty2006-09-181-10/+8
| | | | | | | | | | 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 #28Manuel M T Chakravarty2006-08-041-4/+36
| | | | | | | | 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-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+549
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