This project is mirrored from 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. 09 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Typechecking for "foreign import prim" · 2da37f4f
      Duncan Coutts authored
      The main restriction is that all args and results must be unboxed types.
      In particular we allow unboxed tuple results (which is a primary
      motivation for the whole feature). The normal rules apply about
      "void rep" result types like State#. We only allow "prim" calling
      convention for import, not export. The other forms of import, "dynamic",
      "wrapper" and data label are banned as a conseqence of checking that the
      imported name is a valid C string. We currently require prim imports to
      be marked unsafe, though this is essentially arbitrary as the safety
      information is unused.
  2. 27 May, 2009 1 commit
    •'s avatar
      Template Haskell: allow type splices · 389cca21 authored
      At last!  Trac #1476 and #3177
      This patch extends Template Haskell by allowing splices in
      types.  For example
        f :: Int -> $(burble 3)
      A type splice should work anywhere a type is expected.  This feature
      has been long requested, and quite a while ago I'd re-engineered the
      type checker to make it easier, but had never got around to finishing
      the job.  With luck, this does it.
      There's a ToDo in the HsSpliceTy case of RnTypes.rnHsType, where I
      am not dealing properly with the used variables; but that's awaiting
      the refactoring of the way we report unused names.
  3. 27 Apr, 2009 1 commit
    •'s avatar
      Equality constraint solver is now externally pure · 296058a1 authored
      - This patch changes the equality constraint solver such that it does not
        instantiate any type variables that occur in the constraints that are to be
        solved (or in the environment).  Instead, it returns a bag of type bindings.
      - If these type bindings (together with the other results of the solver) are
        discarded, solver invocation has no effect (outside the solver) and can be
        repeated (that's imported for TcSimplifyRestricted).
      - For the type bindings to take effect, the caller of the solver needs to 
        execute them. 
      - The solver will still instantiate type variables thet were created during 
        solving (e.g., skolem flexibles used during type flattening).
        See also
  4. 30 Mar, 2009 1 commit
  5. 26 Mar, 2009 1 commit
  6. 05 Mar, 2009 2 commits
  7. 03 Mar, 2009 1 commit
  8. 25 Nov, 2008 1 commit
  9. 25 Sep, 2008 1 commit
  10. 10 Sep, 2008 1 commit
  11. 03 Sep, 2008 1 commit
    •'s avatar
      Major change in compilation of instance declarations (fix Trac #955, #2328) · f16dbbbe authored
      This patch makes an important change to the way that dictionary
      functions are handled.  Before, they were unconditionally marked
      INLIINE, but all the code written by the user in the instance
      was inside that unconditionally-inlined function.  Result: massive
      code bloat in programs that use complicated instances.
      This patch make instances behave rather as if all the methods
      were written in separate definitions.  That dramatically reduces
      bloat.  The new plan is described in TcInstDcls
      	Note [How instance declarations are translated]
      Everything validates.  The major code-bloat bug is squashed: in particular
      DoCon is fine now (Trac #2328) and I believe that #955 is also better.
      Nofib results:
      Binary sizes
              -1 s.d.      +2.5%
              +1 s.d.      +3.1%
              Average      +2.8%
              -1 s.d.      -6.4%
              +1 s.d.      +2.5%
              Average      -2.0%
      Note that 2% improvement.  Some programs improve by 20% (rewrite)!
      Two get slightly worse: pic (2.1%), and gameteb (3.2%), but all others
      improve or stay the same.
      I am not absolutely 100% certain that all the corners are correct; for
      example, when default methods are marked INLINE, are they inlined?  But
      overall it's better.
      It's nice that the patch also removes a lot of code.  I deleted some
      out of date comments, but there's something like 100 fewer lines of
      code in the new version!  (In the line counts below, there are a lot
      of new comments.)
  12. 31 Jul, 2008 1 commit
  13. 09 Jul, 2008 1 commit
    • Simon Marlow's avatar
      add -fwarn-dodgy-foreign-imports (see #1357) · 3b6382e4
      Simon Marlow authored
      From the entry in the User's guide:
      -fwarn-dodgy-foreign-imports causes a warning to be emitted for
      foreign imports of the following form:
      foreign import "f" f :: FunPtr t
      on the grounds that it probably should be
      foreign import "&f" f :: FunPtr t
      The first form declares that `f` is a (pure) C function that takes no
      arguments and returns a pointer to a C function with type `t`, whereas
      the second form declares that `f` itself is a C function with type
      `t`.  The first declaration is usually a mistake, and one that is hard
      to debug because it results in a crash, hence this warning.
  14. 20 May, 2008 1 commit
  15. 23 Apr, 2008 1 commit
  16. 12 Apr, 2008 1 commit
  17. 29 Mar, 2008 1 commit
  18. 15 Mar, 2008 1 commit
  19. 07 Jan, 2008 1 commit
    •'s avatar
      Make the treatment of equalities more uniform · 3787d987 authored
      This patch (which is part of the fix for Trac #2018) makes coercion variables
      be handled more uniformly.  Generally, they are treated like dictionaries
      in the type checker, not like type variables, but in a couple of places we
      were treating them like type variables.  Also when zonking we should use
      zonkDictBndr not zonkIdBndr.
  20. 06 Nov, 2007 1 commit
  21. 29 Oct, 2007 1 commit
  22. 19 Oct, 2007 1 commit
    •'s avatar
      Zonk quantified tyvars with skolems · cad764aa authored
      We used to zonk quantified type variables to regular TyVars.  However, this
      leads to problems.  Consider this program from the regression test suite:
        eval :: Int -> String -> String -> String
        eval 0 root actual = evalRHS 0 root actual
        evalRHS :: Int -> a
        evalRHS 0 root actual = eval 0 root actual
      It leads to the deferral of an equality
        (String -> String -> String) ~ a
      which is propagated up to the toplevel (see TcSimplify.tcSimplifyInferCheck).
      In the meantime `a' is zonked and quantified to form `evalRHS's signature.
      This has the *side effect* of also zonking the `a' in the deferred equality
      (which at this point is being handed around wrapped in an implication
      Finally, the equality (with the zonked `a') will be handed back to the
      simplifier by TcRnDriver.tcRnSrcDecls calling TcSimplify.tcSimplifyTop.
      If we zonk `a' with a regular type variable, we will have this regular type
      variable now floating around in the simplifier, which in many places assumes to
      only see proper TcTyVars.
      We can avoid this problem by zonking with a skolem.  The skolem is rigid
      (which we requirefor a quantified variable), but is still a TcTyVar that the
      simplifier knows how to deal with.
  23. 11 Oct, 2007 1 commit
  24. 04 Sep, 2007 1 commit
  25. 03 Sep, 2007 1 commit
  26. 01 Sep, 2007 1 commit
  27. 28 Aug, 2007 1 commit
    •'s avatar
      Type checking for type synonym families · 5822cb8d authored
      This patch introduces type checking for type families of which associated
      type synonyms are a special case. E.g.
              type family Sum n m
              type instance Sum Zero n = n
              type instance Sum (Succ n) m = Succ (Sum n m)
              data Zero       -- empty type
              data Succ n     -- empty type
      In addition we support equational constraints of the form:
              ty1 ~ ty2
      (where ty1 and ty2 are arbitrary tau types) in any context where
      type class constraints are already allowed, e.g.
              data Equals a b where
                      Equals :: a ~ b => Equals a b
      The above two syntactical extensions are disabled by default. Enable
      with the -XTypeFamilies flag.
      For further documentation about the patch, see:
              * the master plan
              * the user-level documentation
      The patch is mostly backwards compatible, except for:
              * Some error messages have been changed slightly.
              * Type checking of GADTs now requires a bit more type declarations:
                not only should the type of a GADT case scrutinee be given, but also
                that of any identifiers used in the branches and the return type.
      Please report any unexpected behavior and incomprehensible error message 
      for existing code.
      Contributors (code and/or ideas):
              Tom Schrijvers
              Manuel Chakravarty
              Simon Peyton-Jones
              Martin Sulzmann 
      with special thanks to Roman Leshchinskiy
  28. 09 Aug, 2007 1 commit
  29. 04 Aug, 2007 1 commit
    •'s avatar
      Fix Trac #1037 · f117d08b authored
      It makes *sense* for a foreign import to have a zero-sized return, thus
        foreign import ccall foo :: Int -> State# RealWorld
      but it's not clear that it's useful, and it requires some back-end (a
      Hint for void types) to make it go right through. It's not clear that
      we really want this facility, so rather than fixing the code
      generator, I'm just making the construct illegal for now.
  30. 10 Jul, 2007 1 commit
    • Ian Lynagh's avatar
      Fix tcInstHeadTyNotSynonym · 11e80952
      Ian Lynagh authored
      It was returning False for type variables amongst other things, so
      "instance C a" was telling us to use -XTypeSynonymInstances.
  31. 09 Jul, 2007 1 commit
  32. 08 Jul, 2007 1 commit
  33. 03 Jul, 2007 1 commit
  34. 29 Jun, 2007 1 commit
  35. 28 Jun, 2007 1 commit
  36. 07 May, 2007 1 commit
    •'s avatar
      FIX Trac #1332: make isStringTy work right · 43f19eec authored
      For some ancient reason, TcType.isStringTy was treating newtypes as
      transparent, which is quite consistent with isIntTy, isBoolTy etc.  
      (I think the reason is that isStringTy was written to go with isFFIDotNetTy,
      which deals in representation types.)
      Anyway, this inconsistency is Utterly Wrong when called from 
      Inst.shortCutStringLit, and that made tc224 fail.  I can't think how
      it ever succeeded.  Maybe it never did!
      Anyway this fixes it. It may be that .NET FFI calls are not quite as
      permissive, but they are almost certainly broken in more serious ways,
      so I'm going to jump that bridge if we come to it.
  37. 26 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Give a better error message when we try to print a value of unknown type · 97351f5d
      Simon Marlow authored
        Stopped at ../Test3.hs:(1,0)-(2,30)
        _result :: [a]
        [../Test3.hs:(1,0)-(2,30)] *Main> _result
            Ambiguous type variable `a' in the constraint:
              `Show a' arising from a use of `print' at <interactive>:1:0-6
            Cannot resolve unkonwn runtime types: a
            Use :print or :force to determine these types
  38. 22 Apr, 2007 1 commit
    •'s avatar
      Fixes to datacon wrappers for indexed data types · 70918cf4 authored pointed out (Trac #1204) that indexed data types
      aren't quite right. I investigated and found that the wrapper
      functions for indexed data types, generated in MkId, are really very
      confusing.  In particular, we'd like these combinations to work
      	newtype + indexed data type
      	GADT + indexted data type
      The wrapper situation gets a bit complicated!  
      I did a bit of refactoring, and improved matters, I think.  I am not
      certain that I have gotten it right yet, but I think it's better.
      I'm committing it now becuase it's been on my non-backed-up laptop for
      a month and I want to get it into the repo. I don't think I've broken
      anything, but I don't regard it as 'done'.
  39. 19 Feb, 2007 1 commit