This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 19 Oct, 2006 2 commits
  2. 24 Oct, 2006 1 commit
  3. 23 Oct, 2006 2 commits
  4. 22 Oct, 2006 1 commit
  5. 19 Oct, 2006 1 commit
  6. 22 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix handling of family instances in the presense of this doc stuff · f39ff24b
      chak@cse.unsw.edu.au. authored
      - Not sure whether I do the right thing, because I don't understand the
        doc stuff.  However, the original code was definitely wrong and
        breaking the renaming of family instance declarations.
      - The important point is that in
      
          data instance T pats = rhs
      
        T is *not* a defining occurence of T (similarly as C is not a defining
        occurence in "instance C Int").
      f39ff24b
  7. 21 Oct, 2006 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Fix parent position in RnNames.nubAvails · 9530e792
      chak@cse.unsw.edu.au. authored
      - `RnNames.nubAvails', which amalgamates AvailInfo items that belong to the 
        same parent, needs to be careful that the parent name occurs first if it is
        in the list of subnames at all.  (Otherwise, we can get funny export items
        in ifaces.)
      - I discovered this while debugging family import/exports, but I am pretty 
        sure the bug would also have shown up without using families under the 
        right circumstances.
      9530e792
    • chak@cse.unsw.edu.au.'s avatar
      Fix export of associated families with new name parent story · a00334cc
      chak@cse.unsw.edu.au. authored
      Given
      
        module Exp (T)
        where
      
        class C a where
          data T a :: *
      
      we need the AvailInfo for the export item to be C|{T}, not just T.
      This patch achieves that under the new name parent scheme.
      a00334cc
  8. 20 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix processing of imports involving ATs with the new name parent code · 4f55ec2c
      chak@cse.unsw.edu.au. authored
      Associated types in import lists require special care and the new name
      parent code broke that.  What's the problem?  in the presence of ATs
      the name parent relation can have a depth of two (not just one as in H98).
      Here is an example:
      
        class GMapKey a where
          data GMap a :: * -> *
        instance GMapKey Int where
          data GMap Int v = GMapInt ...
      
      The data constructor GMapInt's parent is GMap whose parent in turn is the 
      class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types 
      have no parents (which is in some places in the code represented by making 
      them their own parent).
      
      I fixed this by extending the information in filterImport's occ_env and
      taking the case of associated types explicitly in consideration when 
      processing the various forms of IE items.
      4f55ec2c
  9. 19 Oct, 2006 4 commits
  10. 18 Oct, 2006 2 commits
  11. 11 Oct, 2006 1 commit
  12. 18 Oct, 2006 7 commits
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Add the primitive type Any, and use it for Dynamics · c128930d
      simonpj@microsoft.com authored
      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
      c128930d
    • simonpj@microsoft.com's avatar
      Add comment about arity · 5e41a5af
      simonpj@microsoft.com authored
      I'm not sure what the significance of the "arity" of a primtive
      TyCon is.  They aren't necessarily saturated, so it's not that.
      
      I rather think that arity is only relevant for 
      	SynTyCon 
      	AlgTyCon
      	CoercionTyCon
      
      This comment (and commit message) is just an aide memoire.
      5e41a5af
    • simonpj@microsoft.com's avatar
      Spelling in comment · 1ee8a6f6
      simonpj@microsoft.com authored
      1ee8a6f6
    • simonpj@microsoft.com's avatar
      Minor refactoring · 0d1fca15
      simonpj@microsoft.com authored
      0d1fca15
    • simonpj@microsoft.com's avatar
      Comments onl · 41c97fdc
      simonpj@microsoft.com authored
      41c97fdc
    • Simon Marlow's avatar
      fix build for 6.4.x and 6.6.x · 5563de10
      Simon Marlow authored
      5563de10
  13. 17 Oct, 2006 2 commits
  14. 16 Oct, 2006 3 commits
  15. 14 Oct, 2006 2 commits
  16. 16 Oct, 2006 4 commits
  17. 13 Oct, 2006 2 commits
  18. 06 Oct, 2006 2 commits