1. 26 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fundeps work even for unary type classes · 801c2637
      Simon Peyton Jones authored
      The functional-dependency improvement functions,
         improveFromAnother
         improveFromInstEnv
      had a side-condition that said the type class has to have at
      least two arguments.  But not so, as Trac #12763 shows:
      
         class C a | -> a where ...
      
      is perfectly legal, albeit a bit of a corner case.
      801c2637
  2. 23 Sep, 2016 1 commit
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      
      At use sites, I went through and chose the unification function
      according to the criteria above.
      
      This patch includes some modest performance improvements as we
      are now doing less work.
      9766b0c8
  3. 12 May, 2016 1 commit
  4. 22 Apr, 2016 1 commit
    • niteria's avatar
      Make benign non-determinism in pretty-printing more obvious · 0f96686b
      niteria authored
      This change takes us one step closer to being able to remove
      `varSetElemsWellScoped`. The end goal is to make every source
      of non-determinism obvious at the source level, so that when
      we achieve determinism it doesn't get broken accidentally.
      
      Test Plan: compile GHC
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2123
      
      GHC Trac Issues: #4012
      0f96686b
  5. 19 Apr, 2016 1 commit
  6. 30 Jan, 2016 1 commit
    • niteria's avatar
      Add asserts to other substitution functions · bb956eb8
      niteria authored
      This adds asserts to `substTys`, `substCo` and `substCos` in
      the same spirit as already existing asserts on `substTy`, protecting
      every possible entry point to `subst_ty` and `subst_co`.
      
      I've replaced the violators with unchecked versions.
      
      Test Plan: ./validate --slow
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1862
      
      GHC Trac Issues: #11371
      bb956eb8
  7. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Avoid recursive use of immSuperClasses · 42c6263f
      Simon Peyton Jones authored
      In fixing Trac #11480 I had omitted to deal with FunDeps.oclose,
      which was making recursive use of immSuperClasses, and hence
      going into a loop in the recursive case.
      
      Solution: use transSuperClasses, which takes care not to.
      42c6263f
  8. 20 Jan, 2016 1 commit
  9. 18 Jan, 2016 2 commits
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
    • Simon Peyton Jones's avatar
      Simplify API to tcMatchTys · 5a62b6ac
      Simon Peyton Jones authored
      Previously tcMatchTys took a set of "template type variables" to
      bind.  But all the calls are top-level, and we always want to
      bind all variables in the template.  So I simplified the API
      by omitting that argument.
      
      There should be no change in behaviour.
      
      Feel free to merge to 8.0 if it helps in merging other patches
      5a62b6ac
  10. 31 Dec, 2015 1 commit
  11. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  12. 24 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactoring around FunDeps · d53d8089
      Simon Peyton Jones authored
      This refactoring was triggered by Trac #10675.
      
      We were using 'improveClsFD' (previously called 'checkClsFD') for
      both
        * Improvement: improving a constraint against top-level instances
        * Consistency: checking when two top-level instances are
          consistent
      
      Using the same code for both seemed attractive at the time, but
      it's just too complicated.  So I've split it:
       * Improvement: improveClsFD
       * Consistency: checkFunDeps
      
      Much clearer now!
      d53d8089
  13. 23 Jul, 2015 1 commit
  14. 10 Jul, 2015 1 commit
  15. 26 Jun, 2015 1 commit
  16. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  17. 14 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert multiple commits · 3cf8ecdc
      Austin Seipp authored
      This reverts multiple commits from Simon:
      
        - 04a484ea Test Trac #10359
        - a9ccd37a Test Trac #10403
        - c0aae6f6 Test Trac #10248
        - eb6ca851 Make the "matchable-given" check happen first
        - ca173aa3 Add a case to checkValidTyCon
        - 51cbad15 Update haddock submodule
        - 6e1174da Separate transCloVarSet from fixVarSet
        - a8493e03 Fix imports in HscMain (stage2)
        - a154944b Two wibbles to fix the build
        - 5910a1bc Change in capitalisation of error msg
        - 130e93aa Refactor tuple constraints
        - 8da785d5 Delete commented-out line
      
      These break the build by causing Haddock to fail mysteriously when
      trying to examine GHC.Prim it seems.
      3cf8ecdc
  18. 13 May, 2015 2 commits
    • Simon Peyton Jones's avatar
      Separate transCloVarSet from fixVarSet · 6e1174da
      Simon Peyton Jones authored
      I wasn't clear about the distinction before, and that led to a bug
      when I refactored FunDeps.oclose to use transCloVarSet; it should
      use fixVarSet.
      6e1174da
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  19. 15 Apr, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix fundep coverage-condition check for poly-kinds · 49d9b009
      Simon Peyton Jones authored
      See Note [Closing over kinds in coverage] in FunDeps.
      I'd already fixed this bug once, for Trac #8391, but I put the
      call to closeOverKinds in the wrong place, so Trac #10109
      failed.  (It checks the /liberal/ coverage condition, which
      
      The fix was easy: move the call to the right place!
      49d9b009
  20. 20 Jan, 2015 1 commit
  21. 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
  22. 03 Dec, 2014 1 commit
  23. 30 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Filter instance visibility based on set of visible orphans, fixes #2182. · 4c834fdd
      Edward Z. Yang authored
      
      
      Summary:
      Amazingly, the fix for this very old bug is quite simple: when type-checking,
      maintain a set of "visible orphan modules" based on the orphans list of
      modules which we explicitly imported.  When we import an instance and it
      is an orphan, we check if it is in the visible modules set, and if not,
      ignore it.  A little bit of refactoring for when orphan-hood is calculated
      happens so that we always know if an instance is an orphan or not.
      
      For GHCi, we preinitialize the visible modules set based on the list of
      interactive imports which are active.
      
      Future work: Cache the visible orphan modules set for GHCi, rather than
      recomputing it every type-checking round.  (But it's tricky what to do when you
      /remove/ a module: you need a data structure a little more complicated than
      just a set of modules.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: new tests and validate
      
      Reviewers: simonpj, austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D488
      
      GHC Trac Issues: #2182
      4c834fdd
  24. 07 Nov, 2014 1 commit
  25. 04 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Get the Untouchables level right in simplifyInfer · e11e1b80
      Simon Peyton Jones authored
      Previously we could get constraints in which the untouchables-level did not
      strictly increase, which is one of the main invariants!
      
      This patch also simplifies and modularises the tricky case of generalising
      an inferred let-binding
      e11e1b80
  26. 26 Sep, 2014 1 commit
    • Simon Peyton Jones's avatar
      Improve error messages from functional dependencies · 1a88f9a4
      Simon Peyton Jones authored
      Reponding to Trac #9612:
      
       * Track the CtOrigin of a Derived equality, arising from a
         functional dependency
      
       * And report it clearly in the error stream
      
      This relies on a previous commit, in which I stop dropping Derived
      insolubles on the floor.
      1a88f9a4
  27. 25 Jul, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor FFI error messages · 92587bfe
      Simon Peyton Jones authored
      This patch was provoked by Trac #5610, which I finally got a moment to look at.
      
      In the end I added a new data type ErrUtils.Validity,
      
        data Validity
          = IsValid            -- Everything is fine
          | NotValid MsgDoc    -- A problem, and some indication of why
      
      with some suitable combinators, and used it where appropriate (which touches
      quite a few modules).  The main payoff is that error messages improve for
      FFI type validation.
      92587bfe
  28. 23 May, 2014 1 commit
  29. 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
  30. 04 Dec, 2013 1 commit
  31. 02 Dec, 2013 1 commit
  32. 06 Nov, 2013 1 commit
  33. 01 Nov, 2013 1 commit
  34. 09 Oct, 2013 1 commit
  35. 03 Oct, 2013 1 commit
  36. 01 Oct, 2013 3 commits