1. 06 Jun, 2008 3 commits
    • Ian Lynagh's avatar
      dc2a0e66
    • simonpj@microsoft.com's avatar
      f87698f5
    • 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.
       
      1c05d4fb
  2. 05 Jun, 2008 5 commits
    • simonpj@microsoft.com's avatar
      Vital follow-up to fix of Trac #2045 · 04d0ebc9
      simonpj@microsoft.com authored
      Sorry -- my 'validate' didn't work right and I missed a trick.
      This patch must accompany
      
       * Fix Trac #2045: use big-tuple machiney for implication constraints
      
      04d0ebc9
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Comments only · 9aa2708b
      simonpj@microsoft.com authored
      9aa2708b
    • simonpj@microsoft.com's avatar
      Desugar multiple polymorphic bindings more intelligently · a3f24157
      simonpj@microsoft.com authored
      Occasionally people write very large recursive groups of definitions. 
      In general we desugar these to a single definition that binds tuple,
      plus lots of tuple selectors.  But that code has quadratic size, which
      can be bad.
      
      This patch adds a new case to the desugaring of bindings, for the
      situation where there are lots of polymorphic variables, but no
      dictionaries.  (Dictionaries force us into the general case.)
      
      See Note [Abstracting over tyvars only].  
      
      The extra behaviour can be disabled with the (static) flag
      
      	-fno-ds-multi-tyvar
      
      in case we want to experiment with switching it on or off.  There is
      essentially-zero effect on the nofib suite though.
      
      I was provoked into doing this by Trac #1136.  In fact I'm not sure
      it's the real cause of the problem there, but it's a good idea anyway.
      a3f24157
    • simonpj@microsoft.com's avatar
      Add non-recursive let-bindings for types · 1b1190e0
      simonpj@microsoft.com authored
      This patch adds to Core the ability to say
      	let a = Int in <body>
      where 'a' is a type variable.  That is: a type-let.
      See Note [Type let] in CoreSyn.
      
      * The binding is always non-recursive
      * The simplifier immediately eliminates it by substitution 
      
      So in effect a type-let is just a delayed substitution.  This is convenient
      in a couple of places in the desugarer, one existing (see the call to
      CoreTyn.mkTyBind in DsUtils), and one that's in the next upcoming patch.
      
      The first use in the desugarer was previously encoded as
      	(/\a. <body>) Int
      rather that eagerly substituting, but that was horrid because Core Lint
      had do "know" that a=Int inside <body> else it would bleat.  Expressing
      it directly as a 'let' seems much nicer.
      
      1b1190e0
  3. 04 Jun, 2008 9 commits
  4. 03 Jun, 2008 1 commit
  5. 30 May, 2008 2 commits
  6. 03 Jun, 2008 7 commits
  7. 02 Jun, 2008 6 commits
  8. 30 May, 2008 1 commit
    • Simon Marlow's avatar
      Fix a bug to do with recursive modules in one-shot mode · d83e1ac4
      Simon Marlow authored
      The problem was that when loading interface files in checkOldIface, we
      were not passing the If monad the mutable variable for use when
      looking up entities in the *current* module, with the result that the
      knots wouldn't be tied properly, and some instances of TyCons would
      be incorrectly abstract.
      
      This bug has subtle effects: for example, recompiling a module without
      making any changes might lead to a slightly different result (noticed
      due to the new interface-file fingerprints).  The bug doesn't lead to
      any direct failures that we're aware of.
      d83e1ac4
  9. 29 May, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Replacing copyins and copyouts with data-movement instructions · 0d80489c
      dias@eecs.harvard.edu authored
      o Moved BlockId stuff to a new file to avoid module recursion
      o Defined stack areas for parameter-passing locations and spill slots
      o Part way through replacing copy in and copy out nodes
        - added movement instructions for stack pointer
        - added movement instructions for call and return parameters
          (but not with the proper calling conventions)
      o Inserting spills and reloads for proc points is now procpoint-aware
        (it was relying on the presence of a CopyIn node as a proxy for
         procpoint knowledge)
      o Changed ZipDataflow to expect AGraphs (instead of being polymorphic in
         the type of graph)
      0d80489c
  10. 30 May, 2008 2 commits
  11. 29 May, 2008 3 commits