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. 10 Apr, 2015 1 commit
  2. 09 Apr, 2015 1 commit
  3. 07 Mar, 2015 1 commit
  4. 02 Mar, 2015 1 commit
  5. 10 Feb, 2015 1 commit
  6. 18 Dec, 2014 1 commit
    • Iavor S. Diatchki's avatar
      Add a provenance field to universal coercions. · 1d4e94d1
      Iavor S. Diatchki authored
      Universal coercions allow casting between arbitrary types, so it is a
      good idea to keep track where they came from, which now we can do by
      using the provenance field in `UnivCo`.
      
      This is also handy for type-checker plugins that provide functionality
      beyond what's expressible by GHC's standard coercions:  such plugins
      can generate universal coercions, but they should still tag them,
      so that if something goes wrong we can link the casts to the plugin.
      1d4e94d1
  7. 12 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite `Coercible` solver · 0cc47eb9
      eir@cis.upenn.edu authored
      Summary:
      This is a rewrite of the algorithm to solve for Coercible "instances".
      
      A preliminary form of these ideas is at
      https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver
      
      The basic idea here is that the `EqPred` constructor of `PredTree`
      now is parameterised by a new type `EqRel` (where
      `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
      now talk about nominal equality (the usual case) or representational
      equality (the `Coercible` case).
      
      This is a change from the previous
      behavior where `Coercible` was just considered a regular class with
      a special case in `matchClassInst`.
      
      Because of this change, representational equalities are now
      canonicalized just like nominal ones, allowing more equalities
      to be solved -- in particular, the case at the top of #9117.
      
      A knock-on effect is that the flattener must be aware of the
      choice of equality relation, because the inert set now stores
      both representational inert equalities alongside the nominal
      inert equalities. Of course, we can use representational equalities
      to rewrite only within another representational equality --
      thus the parameterization of the flattener.
      
      A nice side effect of this change is that I've introduced a new
      type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
      in the flattener.
      
      This commit includes some refactoring as discussed on D546.
      It also removes the ability of Deriveds to rewrite Deriveds.
      
      This fixes bugs #9117 and #8984.
      
      Reviewers: simonpj, austin, nomeata
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D546
      
      GHC Trac Issues: #9117, #8984
      0cc47eb9
  8. 01 Dec, 2014 1 commit
  9. 04 Nov, 2014 1 commit
  10. 21 Sep, 2014 1 commit
  11. 19 Sep, 2014 1 commit
    • Simon Peyton Jones's avatar
      Clean up Coercible handling, and interaction of data families with newtypes · 0aaf812e
      Simon Peyton Jones authored
      This patch fixes Trac #9580, in which the Coercible machinery succeeded
      even though the relevant data constructor was not in scope.
      
      As usual I got dragged into a raft of refactoring changes,
      all for the better.
      
      * Delete TcEvidence.coercionToTcCoercion (now unused)
      
      * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
        and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
        (They both return TcCoercions.)
      
      * tcInstNewTyConTF_maybe also gets more convenient type,
        which improves TcInteract.getCoercibleInst
      
      * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
        (as well as in tcInstNewTyConTF_maybe)
      
      * Improve error report for Coercible errors, when data familes
        are involved  Another use of tcLookupDataFamInst
      
      * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
        local hacky code
      
      * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
        with eta-reduced newtypes, using
        (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX
      
      Some small refactoring of TcSMonad.matchFam.
      0aaf812e
  12. 29 Aug, 2014 1 commit
  13. 21 Jul, 2014 1 commit
  14. 18 Jul, 2014 1 commit
  15. 17 Jul, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Workaround haddock parser error caused by 5e7406d9 · 3b8b826b
      Herbert Valerio Riedel authored
      Haddock complains if a comment looks like a misplaced Haddock-comment.
      In this case, the comment line starting with `-- *kind* and` looked like a
      section-heading to Haddock and caused the following error:
      
          parse error on input ‘-- *kind* and role of its argument. Luckily, laziness should’
      
      This commit just rewraps the line so that no `*` appear at the start of the
      non-Haddock comment lines.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      3b8b826b
  16. 16 Jul, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite coercionRole. (#9233) · 34ec0bd9
      eir@cis.upenn.edu authored
      Summary:
      coercionRole is now much more efficient, computing both the coercion's
      kind and role together. The previous version calculated them separately,
      leading to quite possibly exponential behavior.
      
      This is still too slow, but it's a big improvement.
      
      Test Plan: Evaluate by running the "minimized" test from the Trac ticket.
      
      Reviewers: simonpj, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D73
      34ec0bd9
  17. 03 Jun, 2014 1 commit
  18. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  19. 13 May, 2014 1 commit
  20. 12 May, 2014 1 commit
  21. 06 May, 2014 1 commit
    • Simon Peyton Jones's avatar
      Modularise pretty-printing for foralls · 3c3ce829
      Simon Peyton Jones authored
      See TypeRep.pprUserForAll.  This just makes forall-printing a bit more
      consistent.  In particular, I wasn't seeing the kind foralls when
      displaying a CoAxiom or CoAxBranch
      
      The output on T7939 is just possible a bit too verbose now, but even if so
      that's an error in the right direction.
      3c3ce829
  22. 29 Apr, 2014 1 commit
  23. 28 Apr, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Improve implementation of unSubCo_maybe. · a3896ab5
      eir@cis.upenn.edu authored
      This is the result of an email conversation (off list) with
      Conal Elliott, who needed a stronger unSubCo_maybe. This
      commit adds cases to upgrade the role of a coercion when
      recursion is necessary to do say (for example, for a use of
      TransCo). As a side effect, more coercion optimizations are
      now possible.
      
      This was not done previously because unSubCo_maybe was used
      only during coercion optimization, and the recursive cases
      looked to be unlikely. However, adding them can cause no harm.
      
      unSubCo_maybe is now also exported from Coercion, for use
      cases like Conal's.
      a3896ab5
  24. 20 Jan, 2014 1 commit
  25. 12 Jan, 2014 1 commit
  26. 02 Dec, 2013 1 commit
  27. 27 Nov, 2013 1 commit
    • Joachim Breitner's avatar
      Roleify TcCoercion · 9d643cf6
      Joachim Breitner authored
      Previously, TcCoercion were only used to represent boxed Nominal
      coercions. In order to also talk about boxed Representational coercions
      in the type checker, we add Roles to TcCoercion. Again, we closely
      mirror Coercion.
      
      The roles are verified by a few assertions, and at the latest after
      conversion to Coercion. I have put my trust in the comprehensiveness of
      the testsuite here, but any role error after desugaring popping up now
      might be caused by this refactoring.
      9d643cf6
  28. 24 Oct, 2013 3 commits
  29. 23 Oct, 2013 2 commits
  30. 01 Oct, 2013 1 commit
  31. 18 Sep, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Change role annotation syntax. · f4046b50
      eir@cis.upenn.edu authored
      This fixes bugs #8185, #8234, and #8246. The new syntax is explained
      in the comments to #8185, appears in the "Roles" subsection of the
      manual, and on the [wiki:Roles] wiki page.
      
      This change also removes the ability for a role annotation on type
      synonyms, as noted in #8234.
      f4046b50
  32. 13 Sep, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Add support for evaluation of type-level natural numbers. · 1f77a534
      Iavor S. Diatchki authored
      This patch implements some simple evaluation of type-level expressions
      featuring natural numbers.  We can evaluate *concrete* expressions that
      use the built-in type families (+), (*), (^), and (<=?), declared in
      GHC.TypeLits.   We can also do some type inference involving these
      functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
      we can infer that `x` must be 3.  Note, however, this is used only to
      resolve unification variables (i.e., as a form of a constraint improvement)
      and not to generate new facts.  This is similar to how functional
      dependencies work in GHC.
      
      The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
      of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
      generate when we solve a constraint, such as `(1 + 2) ~ 3`.
      
      The patch also adds support for built-in type-families, by adding a new
      form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
      constructors contain a record with functions that are used by the
      constraint solver to simplify and improve constraints involving the
      built-in function (see `TcInteract`).  The record in defined in `FamInst`.
      
      The type constructors and rules for evaluating the type-level functions
      are in a new module called `TcTypeNats`.
      1f77a534
  33. 03 Sep, 2013 1 commit
  34. 02 Aug, 2013 1 commit
  35. 27 Jul, 2013 1 commit
  36. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
      569b2652
  37. 19 Jun, 2013 1 commit