1. 27 Jan, 2016 1 commit
    • niteria's avatar
      Rename "open" subst functions · 5dcae88b
      niteria authored
      This is the renaming that @simonpj requested:
      ```
      · zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)
      
      · zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
      covars)
      
      · zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
      with TyBinders, not covars)
      ```
      plus the `mk` variant.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1853
      
      GHC Trac Issues: #11371
      5dcae88b
  2. 26 Jan, 2016 1 commit
    • niteria's avatar
      Construct in_scope set in mkTopTCvSubst · 144ddb41
      niteria authored
      The pre-condition on `mkTopTCvSubst` turned out to be wrong and
      not satisfied by any of the callers. I've fixed it, so that it
      constructs the in_scope set from the range of the substitution.
      `mkTopTCvSubst` was also unnecessarily general it is never called
      with `CoVars`, so I changed the type signature and added an assertion.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1801
      
      GHC Trac Issues: #11371
      144ddb41
  3. 19 Jan, 2016 1 commit
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      
      It also includes a couple of fixes that I've already done.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1792
      
      GHC Trac Issues: #11371
      9d33adb6
  4. 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
  5. 31 Dec, 2015 1 commit
  6. 24 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactoring only · 1af0d36b
      Simon Peyton Jones authored
      This moves code around to more sensible places.
      
      - Construction for CoAxiom is localised in FamInstEnv
      
      - orphNamesOfxx moves to CoreFVs
      
      - roughMatchTcs, instanceCantMatch moves to Unify
      
      - mkNewTypeCo moves from Coercion to FamInstEnv, and is
        renamed mkNewTypeCoAxiom, which makes more sense
      1af0d36b
  7. 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
  8. 09 Dec, 2015 1 commit
  9. 04 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix egregious error in eta-reduction of data families · 1160dc51
      Simon Peyton Jones authored
      This terrible and long-standing bug was shown up by Trac #11148.
      We are trying to eta-reduce a data family instance, so that we
      can then derive Functor or Generic.  But we were assuming, for
      absolutely not reason whatsoever, that the type variables were
      lined up in a convenient order.  The fact that it ever worked
      was a fluke.
      
      This patch fixes it properly.  Main change is in eta_reduce
      in TcInstDcls.tcDataFamInstDecl
      1160dc51
  10. 21 Sep, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor BranchLists. · cd2840a7
      eir@cis.upenn.edu authored
      Now we use Array to store branches. This makes sense because we often
      have to do random access (once inference is done). This also vastly
      simplifies the awkward BranchList type.
      
      This fixes #10837 and updates submodule utils/haddock.
      cd2840a7
  11. 11 Sep, 2015 1 commit
  12. 03 Sep, 2015 1 commit
  13. 04 Aug, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10713. · f063bd54
      eir@cis.upenn.edu authored
      When doing the apartness/flattening thing, we really only need to
      eliminate non-generative tycons, not *all* families. (Data families
      are indeed generative!)
      f063bd54
  14. 02 Aug, 2015 1 commit
  15. 01 Aug, 2015 1 commit
  16. 26 Jun, 2015 2 commits
    • Simon Peyton Jones's avatar
      Allow recursive unwrapping of data families · 0b7e538a
      Simon Peyton Jones authored
      When doing strictness analysis, we need to look inside products.
      To avoid unpacking infinitely, we must be careful about
      infinite types.  That in turn is controlled by TyCon.checkRecTc.
      
      For data families like
         data instance T (a,b) = MkT a (T b)
      we want to unpack the thing recursively for types like
        T (Int, (Int, (Int, Int)))
      
      This patch elaborates the checkRecTc mechanism in TyCon, to
      maintain a *count* of how many times a TyCon has shown up,
      rather than just a boolean.
      
      A simple change, and a useful one.  Fixes Trac #10482.
      0b7e538a
    • Simon Peyton Jones's avatar
      Use a Representaional coercion for data families · ff8a6716
      Simon Peyton Jones authored
      When we have
        data instance T (a,b) = MkT a b
      we make a represntation type
        data TPair a b = MkT a b
      plus an axiom to connect the two
        ax a b :: T (a,b)  ~R  TPair a b
      
      Previously this was a Nominal equality, and that worked ok
      but seems illogical since Nominal equalities are between
      types that the programmer thinks of as being equal.  But
      TPair is not visible to the programmer; indeed we call it
      the "representation TyCon".  So a Representational equality
      seems more suitable here.
      ff8a6716
  17. 19 Jun, 2015 1 commit
  18. 05 Jun, 2015 1 commit
  19. 04 May, 2015 1 commit
    • Adam Gundry's avatar
      Permit empty closed type families · 4efa4213
      Adam Gundry authored
      Fixes #9840 and #10306, and includes an alternative resolution to #8028.
      This permits empty closed type families, and documents them in the user
      guide. It updates the Haddock submodule to support the API change.
      
      Test Plan: Added `indexed-types/should_compile/T9840` and updated
      `indexed-types/should_fail/ClosedFam4` and `th/T8028`.
      
      Reviewers: austin, simonpj, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: bgamari, jstolarek, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D841
      
      GHC Trac Issues: #9840, #10306
      4efa4213
  20. 04 Mar, 2015 1 commit
  21. 03 Mar, 2015 1 commit
  22. 02 Mar, 2015 1 commit
  23. 17 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426) · 67a0cab6
      Simon Peyton Jones authored
      There were two related bugs here
      
      Trac #9426
         We must increment the ic_mod_index field of the InteractiveContext
         if we have new instances, because we maek DFunIds that should be
         distinct from previous ones.  Previously we were only incrementing
         when defining new user-visible Ids.
      
         The main change is in HscTypes.extendInteractiveContext, which now
         alwyas bumps the ic_mod_index.  I also added a specialised
         extendInteractiveContextWithIds for the case where we are *only*
         adding new user-visible Ids.
      
      Trac #9424
         In HscMain.hscDeclsWithLocations we were failing to use the
         *tidied* ClsInsts; but the un-tidied ones are LocalIds which
         causes a later ASSERT error.
      
         On the way I realised that, to behave consistently, the tcg_insts
         and tcg_fam_insts field of TcGblEnv should really only contain
         instances from the current GHCi command, not all the ones to date.
         That in turn meant I had to move the code for deleting replacement
         instances from addLocalInst, addLocalFamInst to
         HscTypes.extendInteractiveContext
      67a0cab6
  24. 13 Dec, 2014 1 commit
  25. 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
  26. 01 Dec, 2014 1 commit
  27. 28 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename some of the functions in NameSet, to make the uniform with VarSet etc · 7460dafa
      Simon Peyton Jones authored
      For ages NameSet has used different names,
        eg.   addOneToNameSet   rather than    extendNameSet
              nameSetToList     rather than    nameSetElems
      
      etc.  Other set-like modules use uniform naming conventions.
      This patch makes NameSet follow suit.
      
      No change in behaviour; this is just renaming.
      
      I'm doing this just before the fork so that merging is easier.
      7460dafa
  28. 20 Nov, 2014 1 commit
    • Jan Stolarek's avatar
      Split SynTyCon to SynonymTyCon and FamilyTyCon · 696fc4ba
      Jan Stolarek authored
      This patch refactors internal representation of type synonyms and type families by splitting them into two separate data constructors of TyCon data type. The main motivation is is that some fields make sense only for type synonyms and some make sense only for type families. This will be even more true with the upcoming injective type families.
      
      There is also some refactoring of names to keep the naming constistent. And thus tc_kind field has become tyConKind and tc_roles has become tcRoles. Both changes are not visible from the outside of TyCon module.
      
      Updates haddock submodule
      
      Reviewers: simonpj
      
      Differential Revision: https://phabricator.haskell.org/D508
      
      GHC Trac Issues: #9812
      696fc4ba
  29. 04 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix reduceTyFamApp_maybe · fd46acf1
      Simon Peyton Jones authored
      This function previously would expand *data* families even when it was asked
      for a *Nominal* coercion.  This patch fixes it, and adds comments.
      fd46acf1
  30. 21 Oct, 2014 1 commit
  31. 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
  32. 01 Aug, 2014 1 commit
  33. 31 Jul, 2014 2 commits
    • Simon Peyton Jones's avatar
      Complete work on new OVERLAPPABLE/OVERLAPPING pragmas (Trac #9242) · 1ae5fa45
      Simon Peyton Jones authored
      * Deprecate -XOverlappingInstances
      
      * Update test suite.  Several tests even had entirely unnecessary
        uses of -XOverlappingInstances
      
      * Update user manual with a careful description of the instance
        resolution story
      
      * Fix an outright bug in the handling of duplidate instances in GHCi,
        which are meant to silently overwrite the earlier duplicate. The
        logic was right for family instances but was both more complicated,
        and plain wrong, for class instances.  (If you are interested, the
        bug was that we were eliminating the duplicate from the InstEnv, but
        not from the [ClsInst] held in tcg_insts.)  Test is ghci044a.
      1ae5fa45
    • Simon Peyton Jones's avatar
      Comments and white space · 0be7c2cf
      Simon Peyton Jones authored
      0be7c2cf
  34. 03 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do pretty-printing of TyThings via IfaceDecl (Trac #7730) · b4856f9f
      Simon Peyton Jones authored
      All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
      thank you!
      
      I reviewed the patch, started some tidying, up and then ended up in a huge
      swamp of changes, not all of which I can remember now.  But:
      
      * To suppress kind arguments when we have -fno-print-explicit-kinds,
          - IfaceTyConApp argument types are in a tagged list IfaceTcArgs
      
      * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.
      
      * When printing data/type family instances for the user, I've made them
        print out an informative RHS, which is a new feature. Thus
              ghci> info T
              data family T a
              data instance T Int = T1 Int Int
              data instance T Bool = T2
      
      * In implementation terms, pprIfaceDecl has just one "context" argument,
        of type IfaceSyn.ShowSub, which says
             - How to print the binders of the decl
               see note [Printing IfaceDecl binders] in IfaceSyn
             - Which sub-comoponents (eg constructors) to print
      
      * Moved FastStringEnv from RnEnv to OccName
      
      It all took a ridiculously long time to do.  But it's done!
      b4856f9f
  35. 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
  36. 22 Mar, 2014 2 commits