Rejig the way in which generic default method signatures are checked - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer!
Simon's fixes to the generated type instances in Generics
Merge branch 'master' of darcs.haskell.org/ghc into ghc-generics Resolved conflicts: compiler/typecheck/TcTyClsDecls.lhs
Remove the hasGenerics field of TyCon, improve the way the Generics flags is handled, allow for standalone deriving of Representable0.
This BIG PATCH contains most of the work for the New Coercion Representation 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
Initial commit for Pedro's new generic default methods (See his Haskell Symposium 2010 paper "A generic deriving mechaism for Haskell")
Tighten up what it means to be an "enumeration data constructor" See Note [Enumeration types] in TyCon, and comments in Trac #4528
Comment on what an "enumeration" type is
Super-monster patch implementing the new typechecker -- at last This major patch implements the new OutsideIn constraint solving algorithm in the typecheker, following our JFP paper "Modular type inference with local assumptions". Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
Comments and formatting to vectoriser
Refactor (again) the handling of default methods This patch fixes Trac #4056, by a) tidying up the treatment of default method names b) removing the 'module' argument to newTopSrcBinder The details aren't that interesting, but the result is much tidier. The original bug was a 'nameModule' panic, caused by trying to find the module of a top-level name. But TH quotes generate Internal top-level names that don't have a module, and that is generally a good thing. Fixing that in turn led to the default-method refactoring, which also makes the Name for a default method be handled in the same way as other derived names, generated in BuildTyCl via a call newImplicitBinder. Hurrah.
Fix Trac #3966: warn about useless UNPACK pragmas 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.
expand comments for #2578 fix
Fix trac #2578 We define empty datatypes as not being enumerations, which means the empty blocks aren't generated.
Remove unused imports
Make record selectors into ordinary functions 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.
Avoid nasty name clash with associated data types (fixes Trac #2888) The main bug was in TcHsType; see Note [Avoid name clashes for associated data types]. However I did a bit of re-factoring while I was abouut it. I'm still a but unhappy with the use of TyCon.setTyConArgPoss; it'd be better to construct the TyCon correctly in the first place. But that means passing an extra parameter to tcTyDecl1... maybe we should do this.
Allow type families to use GADT syntax (and be GADTs) 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.
Comments only: replace ":=:" by "~" (notation for equality predicates)
Remove dataConInstOrigDictsAndArgTys This suspicious function had just one call, in BuildTyCl.mkNewTyConRhs. I've done it another way now, which is tidier.