1. 18 Dec, 2010 1 commit
  2. 18 Sep, 2010 1 commit
  3. 14 Sep, 2010 1 commit
  4. 13 Sep, 2010 1 commit
  5. 15 Jul, 2010 1 commit
  6. 13 Jul, 2010 1 commit
  7. 07 Jul, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #4127 (and hence #4173) · f87cc9cf
      simonpj@microsoft.com authored
      The change involves a little refactoring, so that the default
      method Ids are brought into scope earlier, before the value
      declarations are compiled.  (Since a value decl may contain
      an instance decl in a quote.)
      See Note [Default method Ids and Template Haskell] in
  8. 06 May, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3966: warn about useless UNPACK pragmas · 215ce9f1
      simonpj@microsoft.com authored
      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.
  9. 09 Apr, 2010 1 commit
  10. 10 Feb, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Keep track of explicit kinding in HsTyVarBndr; plus fix Trac #3845 · 836b1e90
      simonpj@microsoft.com authored
      To print HsTypes correctly we should remember whether the Kind on
      a HsTyVarBndr came from type inference, or was put there by the
      user.  See Note [Printing KindedTyVars] in HsTypes.  So instead of
      changing a UserTyVar to a KindedTyVar during kind checking, we
      simply add a PostTcKind to the UserTyVar.
      The change was provoked by Trac #3830, although other changes
      mean that #3830 gets a diferent and better error message now.
      So this patch is simply doing the Right Thing for the future.
      This patch also fixes Trac #3845, which was caused by a *type splice*
      not remembering the free *term variables* mentioned in it.  Result
      was that we build a 'let' when it should have been 'letrec'.
      Hence a new FreeVars field in HsSpliceTy.
      While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind
      on HsSpliceTy instead, just like on the UserTyVar.
  11. 20 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3823, plus warning police in TcRnDriver · dfa43eb4
      simonpj@microsoft.com authored
      The immediate reason for this patch is to fix #3823. This was 
      rather easy: all the work was being done but I was returning
      type_env2 rather than type_env3.  
      An unused-veriable warning would have shown this up, so I fixed all
      the other warnings in TcRnDriver.  Doing so showed up at least two
      genuine lurking bugs.  Hurrah.
  12. 24 Jul, 2009 1 commit
  13. 23 Jul, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add tuple sections as a new feature · 58521c72
      simonpj@microsoft.com authored
      This patch adds tuple sections, so that
      	(x,,z)  means   \y -> (x,y,z)
      Thanks for Max Bolinbroke for doing the hard work.
      In the end, instead of using two constructors in HsSyn, I used
      just one (still called ExplicitTuple) whose arguments can be
      	Present (LHsExpr id)
      or	Missing PostTcType
      While I was at it, I did a bit of refactoring too.
  14. 22 Jul, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Take account of GADTs when reporting patterm-match overlap · 5b494344
      simonpj@microsoft.com authored
      When matching against a GADT, some of the constructors may be impossible.
      For example
      	data T a where
                T1 :: T Int
                T2 :: T Bool
                T3 :: T a
              f :: T Int -> Int
              f T1 = 3
              f T3 = 4
      Here, does not have any missing cases, despite omittting T2, because
      T2 :: T Bool.
      This patch teaches the overlap checker about GADTs, which happily
      turned out to be rather easy even though the overlap checker needs
      a serious rewrite.
  15. 16 Jul, 2009 1 commit
    • Simon Marlow's avatar
      Use names like '$fOrdInt' for dfuns (and TF instances), rather than '$f21' · a6f29db0
      Simon Marlow authored
      2 reasons for this:
        - compilation is more predictable.  Adding or removing an instance
          is less likely to force unnecessary recompilation due to
          renumbering other dfun names.
        - it makes it easier to read Core / C-- / asm
      The names aren't completely deterministic.  To do that, we'd have to
      include package and module names, which would make the symbol names
      long and reduce readability.  So the compromise is that if there's a
      clash, we disambiguate by adding an integer suffix.  This is fairly
      unlikely in practice unless you're using overlapping instances.
      Type family instances are handled in the same way, with the same
      disambiguation strategy.
  16. 06 Jul, 2009 1 commit
  17. 02 Jul, 2009 2 commits
    • chak@cse.unsw.edu.au.'s avatar
    • simonpj@microsoft.com's avatar
      New syntax for GADT-style record declarations, and associated refactoring · 432b9c93
      simonpj@microsoft.com authored
      The main purpose of this patch is to fix Trac #3306, by fleshing out the
      syntax for GADT-style record declraations so that you have a context in 
      the type.  The new form is
         data T a where
           MkT :: forall a. Eq a => { x,y :: !a } -> T a
      See discussion on the Trac ticket.
      The old form is still allowed, but give a deprecation warning.
      When we remove the old form we'll also get rid of the one reduce/reduce
      error in the grammar. Hurrah!
      While I was at it, I failed as usual to resist the temptation to do lots of
      refactoring.  The parsing of data/type declarations is now much simpler and
      more uniform.  Less code, less chance of errors, and more functionality.
      Took longer than I planned, though.
      ConDecl has record syntax, but it was not being used consistently, so I
      pushed that through the compiler.
  18. 25 Jun, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3323: naughty record selectors again · b4108467
      simonpj@microsoft.com authored
      I boobed when I decoupled record selectors from their data types.
      The most straightforward and robust fix means attaching the TyCon
      of a record selector to its IfaceIdInfo, so 
         you'll need to rebuild all .hi files
      That said, the fix is easy.
  19. 13 May, 2009 1 commit
  20. 23 Apr, 2009 1 commit
  21. 30 Mar, 2009 1 commit
  22. 16 Mar, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3092 · cc9a63c2
      simonpj@microsoft.com authored
      We were't checking that a 'data/type instance' was extending a family
      type constructor.
      Merge to 6.10 if we ever release 6.10.3 (or do it for 6.10.2).
  23. 11 Feb, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3017: ensure that we quantify over enough type variables when equalities are involved · e5a8d57c
      simonpj@microsoft.com authored
      The function FunDeps.grow was not doing the right thing when type equality
      constraints were involved.  That wasn't really its fault: its input was
      being filtered by fdPredsOfInsts.
      To fix this I did a bit of refactoring, so that the (revolting) fdPredsOfInsts
      is now less important (maybe we can get rid of it in due course).  The 'grow'
      function moves from FunDeps to
      The main comments are with the first of these, in
      Note [Growing the tau-tvs using constraints] in Inst.
      Push to the branch if conflict free.
  24. 04 Feb, 2009 2 commits
  25. 14 Jan, 2009 1 commit
  26. 02 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Make record selectors into ordinary functions · 9ffadf21
      simonpj@microsoft.com authored
      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
        (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.
  27. 30 Dec, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Avoid nasty name clash with associated data types (fixes Trac #2888) · 46934dd8
      simonpj@microsoft.com authored
      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.
  28. 08 Nov, 2008 1 commit
  29. 21 Oct, 2008 1 commit
  30. 23 Sep, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Allow type families to use GADT syntax (and be GADTs) · 7299e42c
      simonpj@microsoft.com authored
      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.
  31. 20 Sep, 2008 1 commit
  32. 27 Aug, 2008 1 commit
  33. 11 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2412: type synonyms and hs-boot recursion · 1fa3580c
      simonpj@microsoft.com authored
      Max Bolingbroke found this awkward bug, which relates to the way in
      which hs-boot files are handled.
         --> HEADS UP: interface file format change: recompile everything!
      When we import a type synonym, we want to *refrain* from looking at its
      RHS until we've "tied the knot" in the module being compiled.  (Reason:
      the type synonym might ultimately loop back to the module being compiled.)
      To achieve this goal we need to know the *kind* of the synonym without 
      looking at its RHS.  And to do that we need its kind recorded in the interface
      I slightly refactored the way that the IfaceSyn data constructor
      fields work, eliminating the previous tricky re-use of the same field
      as either a type or a kind.
      See Note [Synonym kind loop] in TcIface
  34. 31 Jul, 2008 1 commit
  35. 14 Jul, 2008 1 commit
  36. 23 Jun, 2008 1 commit
  37. 06 Jun, 2008 2 commits
    • Ian Lynagh's avatar
      Fix warnings in TcTyClsDecls · 911dcb32
      Ian Lynagh authored
    • simonpj@microsoft.com's avatar
      Fix Trac #2334: validity checking for type families · 1c05d4fb
      simonpj@microsoft.com authored
      When we deal with a family-instance declaration (TcTyClsDecls.tcFamInstDecl)
      we must check the TyCon for validity; for example, that a newtype has exactly
      one field.  That is done all-at-once for normal declarations, and had been
      forgotten altogether for families.
      I also refactored the interface to tcFamInstDecl1 slightly.
      A slightly separate matter: if there's an error in family instances
      (e.g. overlap) we get a confusing error message cascade if we attempt to
      deal with 'deriving' clauses too; this patch bales out earlier in that case.
      Another slightly separate matter: standalone deriving for family 
      instances can legitimately have more specific types, just like normal
      data decls. For example
         data instance F [a] = ...
         deriving instance (Eq a, Eq b) => Eq (F [(a,b)])
      So tcLookupFamInstExact can a bit more forgiving than it was.