summaryrefslogtreecommitdiff
path: root/compiler/iface/BinIface.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Add silent superclass parameters (again)Simon Peyton Jones2012-06-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Silent superclass parameters solve the problem that the superclasses of a dicionary construction can easily turn out to be (wrongly) bottom. The problem and solution are described in Note [Silent superclass arguments] in TcInstDcls I first implemented this fix (with Dimitrios) in Dec 2010, but removed it again in Jun 2011 becuase we thought it wasn't necessary any more. (The reason we thought it wasn't necessary is that we'd stopped generating derived superclass constraints for *wanteds*. But we were wrong; that didn't solve the superclass-loop problem.) So we have to re-implement it. It's not hard. Main features: * The IdDetails for a DFunId says how many silent arguments it has * A DFunUnfolding describes which dictionary args are just parameters (DFunLamArg) and which are a function to apply to the parameters (DFunPolyArg). This adds the DFunArg type to CoreSyn * Consequential changes to IfaceSyn. (Binary hi file format changes slightly.) * TcInstDcls changes to generate the right dfuns * CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding The thing taht is *not* done yet is to alter the vectoriser to pass the relevant extra argument when building a PA dictionary.
* Move and rename opt_HiVersionIan Lynagh2012-06-181-2/+2
| | | | It isn't really an option at all
* Make -firrefutable-tuples a dynamic flagIan Lynagh2012-06-181-1/+0
|
* Simplify the implementation of Implicit ParametersSimon Peyton Jones2012-06-131-18/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch re-implements implicit parameters via a class with a functional dependency: class IP (n::Symbol) a | n -> a where ip :: a This definition is in the library module GHC.IP. Notice how it use a type-literal, so we can have constraints like IP "x" Int Now all the functional dependency machinery works right to make implicit parameters behave as they should. Much special-case processing for implicit parameters can be removed entirely. One particularly nice thing is not having a dedicated "original-name cache" for implicit parameters (the nsNames field of NameCache). But many other cases disappear: * BasicTypes.IPName * IPTyCon constructor in Tycon.TyCon * CIPCan constructor in TcRnTypes.Ct * IPPred constructor in Types.PredTree Implicit parameters remain special in a few ways: * Special syntax. Eg the constraint (IP "x" Int) is parsed and printed as (?x::Int). And we still have local bindings for implicit parameters, and occurrences thereof. * A implicit-parameter binding (let ?x = True in e) amounts to a local instance declaration, which we have not had before. It just generates an implication contraint (easy), but when going under it we must purge any existing bindings for ?x in the inert set. See Note [Shadowing of Implicit Parameters] in TcSimplify * TcMType.sizePred classifies implicit parameter constraints as size-0, as before the change There are accompanying patches to libraries 'base' and 'haddock' All the work was done by Iavor Diatchki
* Pass DynFlags to the LogActionIan Lynagh2012-06-111-1/+1
| | | | | | | A side-effect is that we can no longer use the LogAction in defaultErrorHandler, as we don't have DynFlags at that point. But all that defaultErrorHandler did is to print Strings as SevFatal, so now it takes a 'FatalMessager' instead.
* Change how macros like ASSERT are definedIan Lynagh2012-06-051-0/+1
| | | | | By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we don't need to kludge things to keep the warning checker happy etc.
* Make traceBinIFaceReading use log_actionIan Lynagh2012-05-281-1/+1
| | | | It was printing directly to stdout
* Allow cases with empty alterantivesSimon Peyton Jones2012-05-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | This patch allows, for the first time, case expressions with an empty list of alternatives. Max suggested the idea, and Trac #6067 showed that it is really quite important. So I've implemented the idea, fixing #6067. Main changes * See Note [Empty case alternatives] in CoreSyn * Various foldr1's become foldrs * IfaceCase does not record the type of the alternatives. I added IfaceECase for empty-alternative cases. * Core Lint does not complain about empty cases * MkCore.castBottomExpr constructs an empty-alternative case expression (case e of ty {}) * CoreToStg converts '(case e of {})' to just 'e'
* Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-03-131-87/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: compiler/coreSyn/CoreLint.lhs compiler/deSugar/DsBinds.lhs compiler/hsSyn/HsTypes.lhs compiler/iface/IfaceType.lhs compiler/rename/RnHsSyn.lhs compiler/rename/RnTypes.lhs compiler/stgSyn/StgLint.lhs compiler/typecheck/TcHsType.lhs compiler/utils/ListSetOps.lhs
| * Simplified serialization of IfaceTyCon, againMax Bolingbroke2012-02-221-85/+8
| | | | | | | | | | | | Jose's patch implementing kind-polymorphic core (09015be8d580bc33f5f1960c8e31d00ba7a459a1) reverted many of the simplifying changes to interface file TyCon serialization I had made in a previous patch (5d7173f9ab8405511f75765e0541a04796d9bd07). Based on the diff I think this was an unintended consequence of how Jose did the merge rather than a real change he intended to make. In fact, as a result of kind-polymorphic core we don't need to treat the Any TyCon specially any longer so my old simplifying changes can be made even simpler: IfaceTyCon is now just a newtype on IfaceExtName.
| * Remove support for CTYPE pragmas on type synonymsIan Lynagh2012-02-221-4/+2
| | | | | | | | | | | | It's not clear whether it's desirable or not, and it turns out that the way we use coercions in GHC means we tend to lose information about type synonyms.
| * Implement the CTYPE pragma; part of the CApiFFI extensionIan Lynagh2012-02-161-4/+8
| | | | | | | | | | | | | | For now, the syntax is type {-# CTYPE "some C type" #-} Foo = ... newtype {-# CTYPE "some C type" #-} Foo = ... data {-# CTYPE "some C type" #-} Foo = ...
* | Add support for type-level "strings".Iavor S. Diatchki2012-01-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | These are types that look like "this" and "that". They are of kind `Symbol`, defined in module `GHC.TypeLits`. For each type-level symbol `X`, we have a singleton type, `TSymbol X`. The value of the singleton type can be named with the overloaded constant `tSymbol`. Here is an example: tSymbol :: TSymbol "Hello"
* | Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-01-241-12/+1
|\ \ | |/ | | | | | | Conflicts: compiler/typecheck/TcEvidence.lhs
| * Remove getDOpts; use getDynFlags insteadIan Lynagh2012-01-191-1/+1
| |
| * Switch to using the time package, rather than old-timeIan Lynagh2012-01-141-11/+0
| |
* | Mainly, rename LiteralTy to LitTySimon Peyton Jones2012-01-131-2/+2
| |
* | Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-01-071-16/+29
|\ \ | |/
| * Major refactoring of CoAxiomsSimon Peyton Jones2012-01-031-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch should have no user-visible effect. It implements a significant internal refactoring of the way that FC axioms are handled. The ultimate goal is to put us in a position to implement "pattern-matching axioms". But the changes here are only does refactoring; there is no change in functionality. Specifically: * We now treat data/type family instance declarations very, very similarly to types class instance declarations: - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with FamInstEnv.FamInst. This change does affect the GHC API, but for the better I think. - Previously, each family type/data instance declaration gave rise to a *TyCon*; typechecking a type/data instance decl produced that TyCon. Now, each type/data instance gives rise to a *FamInst*, by direct analogy with each class instance declaration giving rise to a ClsInst. - Just as each ClsInst contains its evidence, a DFunId, so each FamInst contains its evidence, a CoAxiom. See Note [FamInsts and CoAxioms] in FamInstEnv. The CoAxiom is a System-FC thing, and can relate any two types, whereas the FamInst relates directly to the Haskell source language construct, and always has a function (F tys) on the LHS. - Just as a DFunId has its own declaration in an interface file, so now do CoAxioms (see IfaceSyn.IfaceAxiom). These changes give rise to almost all the refactoring. * We used to have a hack whereby a type family instance produced a dummy type synonym, thus type instance F Int = Bool -> Bool translated to axiom FInt :: F Int ~ R:FInt type R:FInt = Bool -> Bool This was always a hack, and now it's gone. Instead the type instance declaration produces a FamInst, whose axiom has kind axiom FInt :: F Int ~ Bool -> Bool just as you'd expect. * Newtypes are done just as before; they generate a CoAxiom. These CoAxioms are "implicit" (do not generate an IfaceAxiom declaration), unlike the ones coming from family instance declarations. See Note [Implicit axioms] in TyCon On the whole the code gets significantly nicer. There were consequential tidy-ups in the vectoriser, but I think I got them right.
* | Extend GHC's type with a representation for type level literals.Iavor S. Diatchki2011-12-181-0/+17
|/ | | | | Currently, we support only numeric literals but---hopefully---these modifications should make it fairly easy to add other ones, if necessary.
* More changes aimed at improving call stacks.Simon Marlow2011-12-021-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | - Attach a SrcSpan to every CostCentre. This had the side effect that CostCentres that used to be merged because they had the same name are now considered distinct; so I had to add a Unique to CostCentre to give them distinct object-code symbols. - New flag: -fprof-auto-calls. This flag adds an automatic SCC to every call site (application, to be precise). This is typically more useful for call stacks than annotating whole functions. Various tidy-ups at the same time: removed unused NoCostCentre constructor, and refactored a bit in Coverage.lhs. The call stack we get from traceStack now looks like this: Stack trace: Main.CAF (<entire-module>) Main.main.xs (callstack002.hs:18:12-24) Main.map (callstack002.hs:13:12-16) Main.map.go (callstack002.hs:15:21-34) Main.map.go (callstack002.hs:15:21-23) Main.f (callstack002.hs:10:7-43)
* New kind-polymorphic coreJose Pedro Magalhaes2011-11-111-14/+85
| | | | | | | | | This big patch implements a kind-polymorphic core for GHC. The current implementation focuses on making sure that all kind-monomorphic programs still work in the new core; it is not yet guaranteed that kind-polymorphic programs (using the new -XPolyKinds flag) will work. For more information, see http://haskell.org/haskellwiki/GHC/Kinds
* Fix #437: recompilation check includes flagsDavid Terei2011-11-091-0/+4
|
* Clean of BinIfaceDavid Terei2011-11-091-552/+519
|
* Tabs -> SpacesDavid Terei2011-11-091-607/+600
|
* added NOUNPACK pragma (see #2338)Stefan Wehr2011-11-091-1/+3
|
* addDependentFile #4900Greg Weber2011-11-051-9/+31
| | | | | | | | Let GHC know about an external dependency that Template Haskell uses so that GHC can recompile when the dependency changes. No support for ghc -M There is a corresponding addition to the template-haskell library
* Use -fwarn-tabs when validatingIan Lynagh2011-11-041-0/+7
| | | | | We only use it for "compiler" sources, i.e. not for libraries. Many modules have a -fno-warn-tabs kludge for now.
* Overhaul of infrastructure for profiling, coverage (HPC) and breakpointsSimon Marlow2011-11-021-39/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User visible changes ==================== Profilng -------- Flags renamed (the old ones are still accepted for now): OLD NEW --------- ------------ -auto-all -fprof-auto -auto -fprof-exported -caf-all -fprof-cafs New flags: -fprof-auto Annotates all bindings (not just top-level ones) with SCCs -fprof-top Annotates just top-level bindings with SCCs -fprof-exported Annotates just exported bindings with SCCs -fprof-no-count-entries Do not maintain entry counts when profiling (can make profiled code go faster; useful with heap profiling where entry counts are not used) Cost-centre stacks have a new semantics, which should in most cases result in more useful and intuitive profiles. If you find this not to be the case, please let me know. This is the area where I have been experimenting most, and the current solution is probably not the final version, however it does address all the outstanding bugs and seems to be better than GHC 7.2. Stack traces ------------ +RTS -xc now gives more information. If the exception originates from a CAF (as is common, because GHC tends to lift exceptions out to the top-level), then the RTS walks up the stack and reports the stack in the enclosing update frame(s). Result: +RTS -xc is much more useful now - but you still have to compile for profiling to get it. I've played around a little with adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem quite accurately. I plan to add more facilities for stack tracing (e.g. in GHCi) in the future. Coverage (HPC) -------------- * derived instances are now coloured yellow if they weren't used * likewise record field names * entry counts are more accurate (hpc --fun-entry-count) * tab width is now correct (markup was previously off in source with tabs) Internal changes ================ In Core, the Note constructor has been replaced by Tick (Tickish b) (Expr b) which is used to represent all the kinds of source annotation we support: profiling SCCs, HPC ticks, and GHCi breakpoints. Depending on the properties of the Tickish, different transformations apply to Tick. See CoreUtils.mkTick for details. Tickets ======= This commit closes the following tickets, test cases to follow: - Close #2552: not a bug, but the behaviour is now more intuitive (test is T2552) - Close #680 (test is T680) - Close #1531 (test is result001) - Close #949 (test is T949) - Close #2466: test case has bitrotted (doesn't compile against current version of vector-space package)
* Remove some CPPIan Lynagh2011-10-251-12/+8
|
* Change the way IfExtName is serialized so (most) wired-in names get special ↵Max Bolingbroke2011-09-271-128/+163
| | | | | | | | representation This lets IfaceType be dumber, with fewer special cases, because deserialization for more wired-in names will work. Once we have polymorphic kinds we will be able to replace IfaceTyCon with a simple IfExtName.
* move AvailInfo and related things into its own moduleSimon Marlow2011-09-211-0/+1
|
* Merge branch 'no-pred-ty'Max Bolingbroke2011-09-091-57/+33
|\ | | | | | | | | | | | | | | | | | | Conflicts: compiler/iface/BuildTyCl.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/types/Class.lhs compiler/utils/Util.lhs
| * Comments, and rename FactTuple to ConstraintTupleSimon Peyton Jones2011-09-091-4/+4
| |
| * Implement -XConstraintKindMax Bolingbroke2011-09-061-57/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact, this patch adds a new kind Constraint such that: Show :: * -> Constraint (?x::Int) :: Constraint (Int ~ a) :: Constraint And you can write *any* type with kind Constraint to the left of (=>): even if that type is a type synonym, type variable, indexed type or so on. The following (somewhat related) changes are also made: 1. We now box equality evidence. This is required because we want to give (Int ~ a) the *lifted* kind Constraint 2. For similar reasons, implicit parameters can now only be of a lifted kind. (?x::Int#) => ty is now ruled out 3. Implicit parameter constraints are now allowed in superclasses and instance contexts (this just falls out as OK with the new constraint solver) Internally the following major changes were made: 1. There is now no PredTy in the Type data type. Instead GHC checks the kind of a type to figure out if it is a predicate 2. There is now no AClass TyThing: we represent classes as TyThings just as a ATyCon (classes had TyCons anyway) 3. What used to be (~) is now pretty-printed as (~#). The box constructor EqBox :: (a ~# b) -> (a ~ b) 4. The type LCoercion is used internally in the constraint solver and type checker to represent coercions with free variables of type (a ~ b) rather than (a ~# b)
* | Implement associated type defaultsMax Bolingbroke2011-09-091-0/+15
|/ | | | | | | | | | | | | | | | | | | Basically, now you can write: class Cls a where type Typ a type Typ a = Just a And now if an instance does not specify an explicit associated type instance, one will be generated afresh based on that default. So for example this instance: instance Cls Int where Will be equivalent to this one: instance Cls Int where type Typ Int = Just Int
* Export a tiny bit more info with AbstractTyCon (fixes #5424)Simon Peyton Jones2011-09-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | When we compile -O0 we put type constructors in the interface file without their data constructors -- an AbstractTyCon. But in a client module, to give good pattern-match exhaustiveness warnings, we need to know the difference between a data type and a newtype. (The latter can be coerced to another type, but a data type can't.) See Note [Pruning dead case alternatives] in Unify. Because we weren't conveying this info, we were getting bogus warnings about inexhaustive patterm matches with GADTs, and (confusingly) these warnings woudl come and go depending on whether you were compiling with -O. This patch makes AbstractTyCon carry a flag indicating whether the type constructor is "distinct"; two distinct TyCons cannot be coerced into eachother (except by unsafeCoerce, in which case all bets are off). HEADS UP: interface file format changes slightly, so you need to make clean.
* Change the representation of export lists in .hi filesSimon Peyton Jones2011-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently export list in .hi files are partitioned by module export M T(C1,C2) N f,g In each list we only have OccNames, all assumed to come from the parent module M or N resp. This patch changes the representatation so that export lists have full Names: export M.T(M.C1,M.C2), N.f, N.g Numerous advatages * AvailInfo no longer needs to be parameterised; it always contains Names * Fixes Trac #5306. This was the main provocation * Less to-and-fro conversion when reading interface files It's all generally simpler. Interface files should not get bigger, becuase they have a nice compact representation for Names.
* Fix #481: use a safe recompilation check when Template Haskell isSimon Marlow2011-07-201-5/+9
| | | | | | | | | | | | | | | | being used. We now track whether a module used any TH splices in the ModIface (and at compile time in the TcGblEnv and ModGuts). If a module used TH splices last time it was compiled, then we ignore the results of the normal recompilation check and recompile anyway, *unless* the module is "stable" - that is, none of its dependencies (direct or indirect) have changed. The stability test is pretty important - otherwise ghc --make would always recompile TH modules even if nothing at all had changed, but it does require some extra plumbing to get this information from GhcMake into HscMain. test in driver/recomp009
* SafeHaskell: Fix trust check for when safe module importsDavid Terei2011-06-291-2/+6
| | | | trustworthy module in the same package.
* Get rid of the DFunArg type and all its worksSimon Peyton Jones2011-06-231-9/+0
| | | | | | | | This type was mainly there to support silent superclass parameters for dfuns, and they have gone away. So this patch is another minor simplification. (Interface format change; you need to make clean.)
* Remove "silent superclass parameters"Simon Peyton Jones2011-06-221-5/+3
| | | | | | | | | | | | | We introduced silent superclass parameters as a way to avoid superclass loops, but we now solve that problem a different way ("derived" superclass constraints carry no evidence). So they aren't needed any more. Apart from being a needless complication, they broke DoCon. Admittedly in a very obscure way, but still the result is hard to explain. To see the details see Trac #5051, with test case typecheck/should_compile/T5051. (The test is nice and small!)
* SafeHaskell: Move safe haskell flag into Overlap flagDavid Terei2011-06-171-6/+7
| | | | | | For instance decls we no longer store the SafeHaskell mode in this data structure but instead store it as a bool field in the overlap flag structure.
* SafeHaskell: Add safe import flag (not functional)David Terei2011-06-171-2/+6
|
* SafeHaskell: Add Safe & Trustworthy pragmasDavid Terei2011-06-171-1/+8
|
* Propagate scalar variables and tycons for vectorisation through ↵Manuel M T Chakravarty2011-06-031-2/+6
| | | | 'HscTypes.VectInfo'.
* Merge branch 'master' of http://darcs.haskell.org/ghc into ghc-genericsJose Pedro Magalhaes2011-05-121-40/+59
|\ | | | | | | | | Resolved conflicts: compiler/typecheck/TcTyClsDecls.lhs
| * This BIG PATCH contains most of the work for the New Coercion RepresentationSimon Peyton Jones2011-04-191-40/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | See the paper "Practical aspects of evidence based compilation in System FC" * Coercion becomes a data type, distinct from Type * Coercions become value-level things, rather than type-level things, (although the value is zero bits wide, like the State token) A consequence is that a coerion abstraction increases the arity by 1 (just like a dictionary abstraction) * There is a new constructor in CoreExpr, namely Coercion, to inject coercions into terms
* | Remove the hasGenerics field of TyCon, improve the way the Generics flags is ↵Jose Pedro Magalhaes2011-05-021-4/+2
|/ | | | handled, allow for standalone deriving of Representable0.
* Fix recursive superclasses (again). Fixes Trac #4809.simonpj@microsoft.com2010-12-131-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch finally deals with the super-delicate question of superclases in possibly-recursive dictionaries. The key idea is the DFun Superclass Invariant (see TcInstDcls): In the body of a DFun, every superclass argument to the returned dictionary is either * one of the arguments of the DFun, or * constant, bound at top level To establish the invariant, we add new "silent" superclass argument(s) to each dfun, so that the dfun does not do superclass selection internally. There's a bit of hoo-ha to make sure that we don't print those silent arguments in error messages; a knock on effect was a change in interface-file format. A second change is that instead of the complex and fragile "self dictionary binding" in TcInstDcls and TcClassDcl, using the same mechanism for existential pattern bindings. See Note [Subtle interaction of recursion and overlap] in TcInstDcls and Note [Binding when looking up instances] in InstEnv. Main notes are here: * Note [Silent Superclass Arguments] in TcInstDcls, including the DFun Superclass Invariant Main code changes are: * The code for MkId.mkDictFunId and mkDictFunTy * DFunUnfoldings get a little more complicated; their arguments are a new type DFunArg (in CoreSyn) * No "self" argument in tcInstanceMethod * No special tcSimplifySuperClasss * No "dependents" argument to EvDFunApp IMPORTANT It turns out that it's quite tricky to generate the right DFunUnfolding for a specialised dfun, when you use SPECIALISE INSTANCE. For now I've just commented it out (in DsBinds) but that'll lose some optimisation, and I need to get back to this.