1. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  2. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  3. 24 May, 2016 2 commits
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
    • niteria's avatar
      Document some benign nondeterminism · 4c6e69d5
      niteria authored
      I've changed the functions to their nonDet equivalents and explained
      why they're OK there. This allowed me to remove foldNameSet,
      foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly.
      
      Test Plan: ./validate, there should be no change in behavior
      
      Reviewers: simonpj, simonmar, austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2244
      
      GHC Trac Issues: #4012
      4c6e69d5
  4. 20 Apr, 2016 1 commit
    • niteria's avatar
      Rename FV related functions · 2e33320a
      niteria authored
      This is from Simon's suggestion:
      
      * `tyCoVarsOfTypesAcc` is a terrible name for a function with a
        perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
        Similarly others
      
      * `runFVList` is also terrible, but also has a decent type.
        Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).
      
      * `someVars` could be `mkFVs :: [Var] -> FV`.
      2e33320a
  5. 24 Mar, 2016 1 commit
  6. 21 Mar, 2016 2 commits
    • niteria's avatar
      Use the correct in-scope set in coercionKind · 685398eb
      niteria authored
      The free vars of `ty2` need to be in scope to satisfy the substitution
      invariant.
      As far as I can tell we don't have the free vars of `ty2` when
      substituting, so unfortunately we have to compute them.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, simonpj, goldfire
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2024
      
      GHC Trac Issues: #11371
      685398eb
    • eir@cis.upenn.edu's avatar
      Track specified/invisible more carefully. · 35e93797
      eir@cis.upenn.edu authored
      In particular, this allows correct tracking of specified/invisible
      for variables in Haskell98 data constructors and in pattern synonyms.
      GADT-syntax constructors are harder, and are left until #11721.
      
      This was all inspired by Simon's comments to my fix for #11512,
      which this subsumes.
      
      Test case: ghci/scripts/TypeAppData
      
      [skip ci]  (The test case fails because of an unrelated problem
      fixed in the next commit.)
      35e93797
  7. 18 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Improve piResultTys and friends · 4d031cf9
      Simon Peyton Jones authored
      Several things here:
      
      * Re-implement piResultTys so that its substitution has
        the correct in-scope set
      
        That means paying close attention to performance, since as we
        discovered in Trac #11371, it's a heavily used function and
        is often used on ordinary function types, with no foralls to
        worry about substituting.
      
      * Kill off applyTys, which was just the same as piResultTys.
      
      * Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
        rather than repeatedly calling piResultTy.
      4d031cf9
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
      
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      
      * Kill off TyCoRep.substTelescope (never used)
      b5292557
  8. 17 Feb, 2016 1 commit
  9. 08 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Define tyConRolesRepresentational and use it · 489a9a3b
      Simon Peyton Jones authored
      tyConRolesRepresentational is just a version of tyConRolesX, but
      specialised for a Representational argument. Saves a bit of extra
      argument passing and pattern matching, and tyConRolesX was often
      called when we knew the argument role was Representational.
      
      Rather to my surprise this made the compiler allocate 5% less
      for tests T9872{b,c,d}.  At least I think it's this commit.
      Good thing, regardless.
      489a9a3b
    • Simon Peyton Jones's avatar
      Allow foralls in instance decls · 2cf3cac6
      Simon Peyton Jones authored
      This patch finally makes it possible to have explicit
      foralls in an instance decl
         instance forall (a :: *). Eq a => Eq [a] where ...
      
      This is useful to allow kind signatures or indeed
      explicicit kind for-alls; see Trac #11519
      
      I thought it would be really easy, because an instance
      declaration already contains an actual HsSigType, so all
      the syntactic baggage is there.  But in fact it turned
      out that instance declarations were kind-checked a
      little differently, because the body kind of the forall
      is 'Constraint' rather than '*'.
      
      So I fixed that.  There a slight kludge
      (see Note [Body kind of a HsQualTy], but it's still a
      significant improvement.
      
      I also did the usual other round of refactoring,
      improved a few error messages, tidied up comments etc.
      The only significant aspect of all that was
      
        * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy
          These function names suggest that they do something
          complicated, but acutally they do nothing. So I
          killed them.
      
        * Swap the arg order of mkNamedBinder, just so that it is
          convenient to say 'map (mkNamedBinder Invisible) tvs'
      
        * I had to improve isPredTy, to deal with (illegal)
          types like
             (Eq a => Eq [a]) => blah
          See Note [isPeredTy complications] in Type.hs
      
      Still to come: user manual documentation for the
      instance-decl change.
      2cf3cac6
  10. 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
  11. 21 Jan, 2016 1 commit
  12. 18 Jan, 2016 1 commit
    • 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
  13. 31 Dec, 2015 1 commit
  14. 26 Dec, 2015 1 commit
  15. 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
  16. 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
  17. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  18. 21 Nov, 2015 1 commit
    • niteria's avatar
      Create a deterministic version of tyVarsOfType · 2325bd4e
      niteria authored
      I've run into situations where I need deterministic `tyVarsOfType` and
      this implementation achieves that and also brings an algorithmic
      improvement.  Union of two `VarSet`s takes linear time the size of the
      sets and in the worst case we can have `n` unions of sets of sizes
      `(n-1, 1), (n-2, 1)...` making it quadratic.
      
      One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
      in `SetLevels`. When we abstract type variables when floating we want
      them to be abstracted in deterministic order.
      
      Test Plan: harbormaster
      
      Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1468
      
      GHC Trac Issues: #4012
      2325bd4e
  19. 18 Nov, 2015 1 commit
    • msosn's avatar
      Fix inconsistent pretty-printing of type families · c61759d5
      msosn authored
      After the changes, the three functions used to print type families
      were identical, so they are refactored into one.
      
      Original RHSs of data instance declarations are recreated and
      printed in user error messages.
      
      RHSs containing representation TyCons are printed in the
      Coercion Axioms section in a typechecker dump.
      
      Add vbar to the list of SDocs exported by Outputable.
      Replace all text "|" docs with it.
      
      Fixes #10839
      
      Reviewers: goldfire, jstolarek, austin, bgamari
      
      Reviewed By: jstolarek
      
      Subscribers: jstolarek, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1441
      
      GHC Trac Issues: #10839
      c61759d5
  20. 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
  21. 03 Sep, 2015 1 commit
  22. 26 Jun, 2015 1 commit
    • 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
  23. 16 Jun, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor handling of decomposition. · 7eceffb3
      eir@cis.upenn.edu authored
      This adds the significant Note [Decomposing equalities] to
      TcCanonical, trying to sort out the various cases involved.
      
      The only functional change this commit should make is a different
      treatment of data families, which were wrong before (they could
      be decomposed at role R, which is wrong).
      7eceffb3
  24. 01 Jun, 2015 1 commit
  25. 24 Apr, 2015 1 commit
  26. 10 Apr, 2015 1 commit
  27. 09 Apr, 2015 1 commit
  28. 07 Mar, 2015 1 commit
  29. 02 Mar, 2015 1 commit
  30. 10 Feb, 2015 1 commit
  31. 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
  32. 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
  33. 01 Dec, 2014 1 commit
  34. 04 Nov, 2014 1 commit
  35. 21 Sep, 2014 1 commit
  36. 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