1. 16 Apr, 2015 1 commit
  2. 09 Apr, 2015 1 commit
  3. 07 Apr, 2015 1 commit
  4. 19 Mar, 2015 1 commit
  5. 07 Mar, 2015 1 commit
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      The current implementation creates `TyCon` representations on the spot.
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      Reviewers: simonpj, simonmar, austin, hvr
      Reviewed By: austin, hvr
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D652
      GHC Trac Issues: #9858
  6. 19 Jan, 2015 1 commit
    • Eric Seidel's avatar
      Expose source locations via Implicit Parameters of type GHC.Location.Location · c024af13
      Eric Seidel authored
      IPs with this type will always be solved for the current source
      location. If another IP of the same type is in scope, the two locations will be
      appended, creating a call-stack. The Location type is kept abstract so users
      cannot create them, but a Location can be turned into a list of SrcLocs, which
      correspond to individual locations in a program. Each SrcLoc contains a
      package/module/file name and start/end lines and columns.
      The only thing missing from the SrcLoc in my opinion is the name of the
      top-level definition it inhabits. I suspect that would also be useful, but it's
      not clear to me how to extract the current top-level binder from within the
      constraint solver. (Surely I'm just missing something here?)
      I made the (perhaps controversial) decision to have GHC completely ignore
      the names of Location IPs, meaning that in the following code:
          bar :: (?myloc :: Location) => String
          bar = foo
          foo :: (?loc :: Location) => String
          foo = show ?loc
      if I call `bar`, the resulting call-stack will include locations for
      1. the use of `?loc` inside `foo`,
      2. `foo`s call-site inside `bar`, and
      3. `bar`s call-site, wherever that may be.
      This makes Location IPs very special indeed, and I'm happy to change it if the
      dissonance is too great.
      I've also left out any changes to base to make use of Location IPs, since there
      were some concerns about a snowball effect. I think it would be reasonable to
      mark this as an experimental feature for now (it is!), and defer using it in
      base until we have more experience with it. It is, after all, quite easy to
      define your own version of `error`, `undefined`, etc. that use Location IPs.
      Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs
      Reviewers: austin, hvr, simonpj
      Reviewed By: simonpj
      Subscribers: simonmar, rodlogic, carter, thomie
      Differential Revision: https://phabricator.haskell.org/D578
      GHC Trac Issues: #9049
  7. 14 Jan, 2015 1 commit
  8. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Major patch to add -fwarn-redundant-constraints · 32973bf3
      Simon Peyton Jones authored
      The idea was promted by Trac #9939, but it was Christmas, so I did
      some recreational programming that went much further.
      The idea is to warn when a constraint in a user-supplied context is
      redundant.  Everything is described in detail in
        Note [Tracking redundant constraints]
      in TcSimplify.
      Main changes:
       * The new ic_status field in an implication, of type ImplicStatus.
         It replaces ic_insol, and includes information about redundant
       * New function TcSimplify.setImplicationStatus sets the ic_status.
       * TcSigInfo has sig_report_redundant field to say whenther a
         redundant constraint should be reported; and similarly
         the FunSigCtxt constructor of UserTypeCtxt
       * EvBinds has a field eb_is_given, to record whether it is a given
         or wanted binding. Some consequential chagnes to creating an evidence
         binding (so that we record whether it is given or wanted).
       * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
         see Note [Typechecking plan for instance declarations] in
       * Some significant changes to the type checking of instance
         declarations; Note [Typechecking plan for instance declarations]
         in TcInstDcls.
       * I found that TcErrors.relevantBindings was failing to zonk the
         origin of the constraint it was looking at, and hence failing to
         find some relevant bindings.  Easy to fix, and orthogonal to
         everything else, but hard to disentangle.
      Some minor refactorig:
       * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
       * TcClassDcl and TcInstDcls now have their own code for typechecking
         a method body, rather than sharing a single function. The shared
         function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
         and the differences were growing confusing.
       * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
         use it
       * Add new function Bag.catBagMaybes, and use it in TcSimplify
  9. 23 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Eliminate so-called "silent superclass parameters" · a6f0f5ab
      Simon Peyton Jones authored
      The purpose of silent superclass parameters was to solve the
      awkward problem of superclass dictinaries being bound to bottom.
      See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls
      Although the silent-superclass idea worked,
        * It had non-local consequences, and had effects even in Haddock,
          where we had to discard silent parameters before displaying
          instance declarations
        * It had unexpected peformance costs, shown up by Trac #3064 and its
          test case.  In monad-transformer code, when constructing a Monad
          dictionary you had to pass an Applicative dictionary; and to
          construct that you neede a Functor dictionary. Yet these extra
          dictionaries were often never used.  (All this got much worse when
          we added Applicative as a superclass of Monad.) Test T3064
          compiled *far* faster after silent superclasses were eliminated.
        * It introduced new bugs.  For example SilentParametersOverlapping,
          T5051, and T7862, all failed to compile because of instance overlap
          directly because of the silent-superclass trick.
      So this patch takes a new approach, which I worked out with Dimitrios
      in the closing hours before Christmas.  It is described in detail
      in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls.
      Seems to work great!
      Quite a bit of knock-on effect
       * The main implementation work is in tcSuperClasses in TcInstDcls
         Everything else is fall-out
       * IdInfo.DFunId no longer needs its n-silent argument
         * Ditto IDFunId in IfaceSyn
         * Hence interface file format changes
       * Now that DFunIds do not have silent superclass parameters, printing
         out instance declarations is simpler. There is tiny knock-on effect
         in Haddock, so that submodule is updated
       * I realised that when computing the "size of a dictionary type"
         in TcValidity.sizePred, we should be rather conservative about
         type functions, which can arbitrarily increase the size of a type.
         Hence the new datatype TypeSize, which has a TSBig constructor for
         "arbitrarily big".
       * instDFunType moves from TcSMonad to Inst
       * Interestingly, CmmNode and CmmExpr both now need a non-silent
         (Ord r) in a couple of instance declarations. These were previously
         silent but must now be explicit.
       * Quite a bit of wibbling in error messages
  10. 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.
  11. 12 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite `Coercible` solver · 0cc47eb9
      eir@cis.upenn.edu authored
      This is a rewrite of the algorithm to solve for Coercible "instances".
      A preliminary form of these ideas is at
      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 equa...
  12. 03 Dec, 2014 1 commit
  13. 21 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Implement full co/contra-variant subsumption checking (fixes Trac #9569) · b6855422
      Simon Peyton Jones authored
      This is a pretty big patch, but which substantially iproves the subsumption
      check.  Trac #9569 was the presenting example, showing how type inference could
      depend rather delicately on eta expansion.  But there are other less exotic
      examples; see Note [Co/contra-variance of subsumption checking] in TcUnify.
      The driving change is to TcUnify.tcSubType.  But also
      * HsWrapper gets a new constructor WpFun, which behaves very like CoFun:
             if     wrap1 :: exp_arg <= act_arg
                    wrap2 :: act_res <= exp_res
             then   WpFun wrap1 wrap2 : (act_arg -> arg_res) <= (exp_arg -> exp_res)
      * I generalised TcExp.tcApp to call tcSubType on the result,
        rather than tcUnifyType.  I think this just makes it consistent
        with everything else, notably tcWrapResult.
      As usual I ended up doing some follow-on refactoring
      * AmbigOrigin is gone (in favour of TypeEqOrigin)
      * Combined BindPatSigCtxt and PatSigCxt into one
      * Improved a bit of error message generation
  14. 04 Nov, 2014 1 commit
  15. 14 Oct, 2014 1 commit
  16. 26 Sep, 2014 1 commit
  17. 29 Aug, 2014 1 commit
  18. 28 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor unfoldings · 6e0f6ede
      Simon Peyton Jones authored
      There are two main refactorings here
      1.  Move the uf_arity field
             out of CoreUnfolding
             into UnfWhen
          It's a lot tidier there.  If I've got this right, no behaviour
          should change.
      2.  Define specUnfolding and use it in DsBinds and Specialise
           a) commons-up some shared code
           b) makes sure that Specialise correctly specialises DFun
              unfoldings (which it didn't before)
      The two got put together because both ended up interacting in the
      They cause zero difference to nofib.
  19. 01 Aug, 2014 2 commits
  20. 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.
  21. 13 Apr, 2014 1 commit
  22. 25 Mar, 2014 1 commit
    • Simon Peyton Jones's avatar
      Improve the desugaring of RULE left-hand-sides (fixes Trac #8848) · 41ba7ccb
      Simon Peyton Jones authored
      I've added detailed comments with
        Note [Decomposing the left-hand side of a RULE]
      The result is a noticeable improvement.  Previously
       * we rejected a perfectly decent SPECIALISE (Trac #8848)
       * and for something like
            f :: (Eq a) => b -> a -> a
            {-# SPECIALISE f :: b -> [Int] -> [Int] #-}
         we ended up with
            RULE  f ($fdEqList $dfEqInt) = f_spec
         whereas we wanted
            RULES forall (d:Eq [Int]). f d = f_spec
  23. 13 Mar, 2014 1 commit
  24. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      The rundown is this:
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
        * Unidirectional patterns are declared like thus:
              pattern P x <- x:_
          The synonym 'P' may only occur in a pattern context:
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
        * Bidirectional patterns are declared like thus:
              pattern P x y = [x, y]
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
              bar :: Int -> [Int]
              bar x = P x 10
        * Patterns can't yet have their own type signatures; signatures are inferred.
        * Pattern synonyms may not be recursive, c.f. type synonyms.
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
              module Foo (pattern Bar) where ...
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
              pattern P x y <- [x, y]
              f (P True True) = True
              f _             = False
              g [True, True] = True
              g _            = False
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      For more information, see the wiki:
      Reviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  25. 02 Dec, 2013 1 commit
  26. 29 Nov, 2013 1 commit
  27. 28 Nov, 2013 1 commit
  28. 27 Nov, 2013 2 commits
    • Joachim Breitner's avatar
      Get rid of EvCoercible · 808ded9c
      Joachim Breitner authored
      and use EvCoercion to describe the evidence for Coercible instances.
    • 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.
  29. 22 Nov, 2013 1 commit
  30. 20 Nov, 2013 1 commit
    • Joachim Breitner's avatar
      Make Coercible higher-kinded · 976a1087
      Joachim Breitner authored
      This implements #8541. The changes are fully straight forward and work
      nicely for the examples from the ticket; this is mostly due to the
      existing code not checking for saturation and kindness.
  31. 25 Oct, 2013 1 commit
  32. 23 Oct, 2013 2 commits
  33. 01 Oct, 2013 2 commits
  34. 13 Sep, 2013 2 commits
    • Joachim Breitner's avatar
      Introduce coerce :: Coercible a b -> a -> b · 17a868af
      Joachim Breitner authored
      This is the result of the design at
      The goal is to be able to convert between, say [First Int] and [Last
      Int] with zero run-time overhead. To that end, we introduce a special
      two parameter type class Coercible whose instances are created
      automatically and on-the fly. This relies on and exploits the recent
      addition of roles to core.
    • 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`.
  35. 02 Aug, 2013 1 commit