1. 26 Jul, 2017 1 commit
  2. 26 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer Given flatten-skolems · 8dc6d645
      Simon Peyton Jones authored
      The big change here is to fix an outright bug in flattening of Givens,
      albeit one that is very hard to exhibit.  Suppose we have the constraint
          forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ...
       - we'll flatten the (F) b to a fsk, say  (F b ~ fsk1)
       - we'll rewrite the (F b) inside the inner implication to 'fsk1'
       - when we leave the outer constraint we are suppose to unflatten;
         but that fsk1 will still be there
       - if we re-simplify the entire outer implication, we'll re-flatten
         the Given (F b) to, say, (F b ~ fsk2)
      Now we have two fsks standing for the same thing, and that is very
      Solution: make fsks behave more like fmvs:
       - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv
       - We "fill in" that meta-tyvar when leaving the implication
       - The old FlatSkol form of TcTyVarDetails is gone completely
       - We track the flatten-skolems for the current implication in
         a new field of InertSet, inert_fsks.
      See Note [The flattening story] in TcFlatten.
      In doing this I found various other things to fix:
      * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't
        needed.   But I added one in TcSimplify.floatEqualities, which does
        the zonk precisely when it is needed.
      * Trac #13674 showed up a case where we had
           - an insoluble Given,   e.g.  a ~ [a]
           - the same insoluble Wanted   a ~ [a]
        We don't use the Given to rewwrite the Wanted (obviously), but
        we therefore ended up reporting
            Can't deduce (a ~ [a]) from (a ~ [a])
        which is silly.
        Conclusion: when reporting errors, make the occurs check "win"
        See Note [Occurs check wins] in TcErrors
  3. 16 May, 2017 1 commit
  4. 11 Apr, 2017 1 commit
  5. 31 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Clean up coreView/tcView. · 6575f4b6
      Ben Gamari authored
      In Core, Constraint should be considered fully equal to
      TYPE LiftedRep, in all ways. Accordingly, coreView should
      unwrap Constraint to become TYPE LiftedRep. Of course, this
      would be a disaster in the type checker.
      So, where previously we used coreView in both the type checker
      and in Core, we now have coreView and tcView, which differ only
      in their treatment of Constraint.
      Historical note: once upon a past, we had tcView distinct from
      coreView. Back then, it was because newtypes were unwrapped in
      Core but not in the type checker. The distinction is back, but
      for a different reason than before.
      This had a few knock-on effects:
       * The Typeable solver must explicitly handle Constraint to ensure
         that we produce the correct evidence.
       * TypeMap now respects the Constraint/Type distinction
      Finished by: bgamari
      Test Plan: ./validate
      Reviewers: simonpj, austin, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3316
  6. 07 Mar, 2017 1 commit
  7. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
          data TypeRep (a :: k)
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      Library changes
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      We also add a kind heterogeneous type equality type, (:~~:), to
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
  8. 14 Feb, 2017 1 commit
    • Adam Gundry's avatar
      Implement HasField constraint solving and modify OverloadedLabels · da493897
      Adam Gundry authored
      This implements automatic constraint solving for the new HasField class
      and modifies the existing OverloadedLabels extension, as described in
      the GHC proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current
      form of the proposal, it does *not* currently introduce a separate
      `OverloadedRecordFields` extension.
      This replaces D1687.
      The users guide documentation still needs to be written, but I'll do
      that after the implementation is merged, in case there are further
      design changes.
      Test Plan: new and modified tests in overloadedrecflds
      Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D2708
  9. 08 Feb, 2017 1 commit
  10. 02 Feb, 2017 1 commit
  11. 31 Jan, 2017 1 commit
    • Daniel Haraj's avatar
      Use top-level instances to solve superclasses where possible · 748b7974
      Daniel Haraj authored
      This patch introduces a new flag `-fsolve-constant-dicts` which makes the
      constraint solver solve super class constraints with available dictionaries if
      possible. The flag is enabled by `-O1`.
      The motivation of this patch is that the compiler can produce more efficient
      code if the constraint solver used top-level instance declarations to solve
      constraints that are currently solved givens and their superclasses. In
      particular, as it currently stands, the compiler imposes a performance penalty
      on the common use-case where superclasses are bundled together for user
      convenience. The performance penalty applies to constraint synonyms as
      well. This example illustrates the issue:
      {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-}
      module B where
      class M a b where m :: a -> b
      type C a b = (Num a, M a b)
      f :: C Int b => b -> Int -> Int
      f _ x = x + 1
      Output without the patch, notice that we get the instance for `Num Int` by
      using the class selector `p1`.
      f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int
      f =
        \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) ->
          + @ Int
            (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC)
      Output with the patch, nicely optimised code!
      f :: forall b. C Int b => b -> Int -> Int
      f =
        \ (@ b) _ _ (x_azg :: Int) ->
          case x_azg of { GHC.Types.I# x1_a1DP ->
          GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#)
      Reviewers: simonpj, bgamari, austin
      Reviewed By: simonpj
      Subscribers: mpickering, rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D2714
      GHC Trac Issues: #12791, #5835
  12. 23 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Apply the right substitution in ty-fam improvement · 2b64e926
      Simon Peyton Jones authored
      Trac #13135 showed that we were failing to apply the
      correct substitution to the un-substituted tyvars during
      type-family improvement using injectivity.  Specifically
      in TcInteractlinjImproveEqns we need to use instFlexiX.
      An outright bug, easy to fix.
      Slight refactoring along the way.  The quantified tyars of the axiom are
      readily to hand; we don't need to take the free tyvars of the LHS
  13. 25 Nov, 2016 3 commits
    • Simon Peyton Jones's avatar
      Be a bit more selective about improvement · f8c966c7
      Simon Peyton Jones authored
      This patch makes [W] constraints not participate in
      improvement.   See Note [Do not do improvement for WOnly]
      in TcSMonad.
      Removes some senseless work duplication in some cases (notably
      Trac #12860); should not change behaviour.
    • Simon Peyton Jones's avatar
      Refactor functional dependencies a bit · eb55ec29
      Simon Peyton Jones authored
      * Rename CoAxiom.Eqn = Pair Type to TypeEqn,
        and use it for fundeps
      * Use the FunDepEqn for injectivity, which lets us share a bit
        more code, and (more important) brain cells
      * When generating fundeps, take the max depth of the two
        constraints.  This aimed at tackling the strange loop in
        Trac #12860, but there is more to come for that.
      * Improve pretty-printing with -ddump-tc-trace
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
        Trac #12526
        Trac #12444
        Trac #12538
      The main changes are these
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
        See TcSMonad Note [The improvement story and derived shadows]
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      I also did lots of work on comments, including fixing Trac #12821.
  14. 21 Nov, 2016 1 commit
  15. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      Test Plan: Validate
      Reviewers: goldfire, austin
      Subscribers: goldfire, thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D2528
      GHC Trac Issues: #11660
  16. 21 Oct, 2016 1 commit
  17. 10 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Orient improvement constraints better · b255ae7b
      Simon Peyton Jones authored
      This patch fixes an infinite loop in the constraint solver,
      shown up by Trac #12522.
      The solution is /very/ simple: just reverse the orientation of the
      derived constraints arising from improvement using type-family
      injectivity.  I'm not very proud of the fix --- it seems fragile
      --- but it has the very great merit of simplicity, and it works
      See Note [Improvement orientation] in TcInteract, and some
      discussion on the Trac ticket.
  18. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 66a8c194
      Simon Peyton Jones authored
      1. Trac #12593 exposed a long-standing bug in the occurs
         checking machinery.  When unifying two type variables
                a ~ b
         where a /= b, we were assuming that there could be
         no occurs-check error.  But there can: 'a' can occur
         in b's kind!  When the RHS was a non-tyvar we used
         occurCheckExpand, which /did/ look in kinds, but not
         when the RHS was a tyvar.
         This bug has been lurking ever since TypeInType, maybe
         longer.  And it was present both in TcUnify (the on-the-fly
         unifier), and in TcInteract.
         I ended up refactoring both so that the tyvar/tyvar
         path naturally goes through the same occurs-check as
         non-tyvar rhss.  It's simpler and more robust now.
         One good thing is that both unifiers now share
         previously they had different logic for the same goals
      2. Fixing this bug exposed another!  In T11635 we end
         up unifying
         (alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
         Now that the occurs check is done for tyvars too, we
         look inside beta's kind.  And then reject the program
         becuase of the forall inside there.  But in fact that
         forall is fine -- it does not count as impredicative
         polymoprhism.   See Note [Checking for foralls]
         in TcType.
      3. All this fuss around occurrence checking forced me
         to look at TcUnify.checkTauTvUpdate
                and TcType.occurCheckExpand
         There's a lot of duplication there, and I managed
         to elminate quite a bit of it. For example,
         checkTauTvUpdate called a local 'defer_me'; and then
         called occurCheckExpand, which then used a very
         similar 'fast_check'.
         Things are better, but there is more to do.
  19. 28 Sep, 2016 1 commit
  20. 20 Jul, 2016 1 commit
  21. 23 Jun, 2016 1 commit
  22. 22 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Expand given superclasses more eagerly · ce97b729
      Simon Peyton Jones authored
      This patch fixes Trac #12175, another delicate corner case of
      Note [Instance and Given overlap] in TcInteract.
      In #12175 we were not expanding given superclasses eagerly
      enough. It was easy to fix, and is actually rather neater than
      See Note [Eagerly expand given superclasses] in TcCanonical.
      The main change is to move the eager expansion of given superclasses
      to canClassNC.
  23. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
        - tyConBinders :: [TyConBinder]
      The new data types look like this:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      Some smaller points
      * Nice new functions
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
    • 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
  24. 18 May, 2016 1 commit
    • niteria's avatar
      Make inert_model and inert_eqs deterministic sets · fffe3a25
      niteria authored
      The order inert_model and intert_eqs fold affects the order that the
      typechecker looks at things. I've been able to experimentally confirm
      that the order of equalities and the order of the model matter for
      determinism. This is just a straigthforward replacement of
      nondeterministic VarEnv for deterministic DVarEnv.
      Test Plan: ./validate
      Reviewers: simonpj, goldfire, austin, bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2232
      GHC Trac Issues: #4012
  25. 28 Apr, 2016 1 commit
    • niteria's avatar
      Kill varSetElems in injImproveEqns · 82538f65
      niteria authored
      We want to remove varSetElems at the source level because it
      might be a source of nondeterminism. I don't think it introduces
      nondeterminism here, but it's easy to do the same thing
      deterministically for the same price.
      instFlexiTcS :: [TKVar] -> TcS (TCvSubst, [TcType])
      instFlexiTcS currently gives the range of the produced substitution
      as the second element of the tuple, but it's not used anywhere
      right now. If it started to be used in the code I'm modifying
      it would cause nondeterminism problems.
      Test Plan: ./validate
      Reviewers: austin, goldfire, bgamari, simonmar, simonpj
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2149
      GHC Trac Issues: #4012
  26. 22 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      It actually found an example of an over-complicated context in CmmNode.
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      The warning itself is done in TcValidity.check_class_pred.
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
  27. 15 Apr, 2016 1 commit
    • niteria's avatar
      Kill some unnecessary varSetElems · 928d7473
      niteria authored
      When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
      `tyCoVarsOfTypeList x`.
      Why? If you look at the implementation:
      tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty
      tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty
      they use the same helper function. The helper function returns a
      deterministically ordered list and a set. The only difference
      between the two is which part of the result they take. It is redundant
      to take the set and then immediately convert it to a list.
      This helps with determinism and we eventually want to replace the uses
      of `varSetElems` with functions that don't leak the values of uniques.
      This change gets rid of some instances that are easy to kill.
      I chose not to annotate every place where I got rid of `varSetElems`
      with a comment about non-determinism, because once we get rid of
      `varSetElems` it will not be possible to do the wrong thing.
      Test Plan: ./validate
      Reviewers: goldfire, austin, simonmar, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2115
      GHC Trac Issues: #4012
  28. 04 Apr, 2016 1 commit
    • Eric Seidel's avatar
      Don't infer CallStacks · 7407a66d
      Eric Seidel authored
      We originally wanted CallStacks to be opt-in, but dealing with let
      binders complicated things, forcing us to infer CallStacks. It turns
      out that the inference is actually unnecessary though, we can let the
      wanted CallStacks bubble up to the outer context by refusing to
      quantify over them. Eventually they'll be solved from a given CallStack
      or defaulted to the empty CallStack if they reach the top.
      So this patch prevents GHC from quantifying over CallStacks, getting us
      back to the original plan. There's a small ugliness to do with
      PartialTypeSignatures, if the partial theta contains a CallStack
      constraint, we *do* want to quantify over the CallStack; the user asked
      us to!
      Note that this means that
        foo :: _ => CallStack
        foo = getCallStack callStack
      will be an *empty* CallStack, since we won't infer a CallStack for the
      hole in the theta. I think this is the right move though, since we want
      CallStacks to be opt-in. One can always write
        foo :: (HasCallStack, _) => CallStack
        foo = getCallStack callStack
      to get the CallStack and still have GHC infer the rest of the theta.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: bitemyapp, thomie
      Projects: #ghc
      Differential Revision: https://phabricator.haskell.org/D1912
      GHC Trac Issues: #11573
  29. 15 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11401. · 35d37ff8
      eir@cis.upenn.edu authored
      This commit teaches shortCutReduction about Derived constraints.
      [skip ci]
  30. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      This commit also contains a few performance improvements:
      * Short-cut equality checking of nullary type syns
      * Compare types before kinds in eqType
      * INLINE coreViewOneStarKind
      * Store tycon binders separately from kinds.
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      This commit updates the haddock submodule.
  31. 08 Feb, 2016 1 commit
  32. 22 Jan, 2016 1 commit
  33. 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
  34. 18 Jan, 2016 2 commits
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      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
    • Eric Seidel's avatar
      un-wire-in error, undefined, CallStack, and IP · a7b751db
      Eric Seidel authored
      I missed a crucial step in the wiring-in process of `CallStack` in D861,
      the bit where you actually wire-in the Name... This led to a nasty bug
      where GHC thought `CallStack` was not wired-in and tried to fingerprint
      it, which failed because the defining module was not loaded.
      But we don't need `CallStack` to be wired-in anymore since `error` and
      `undefined` no longer need to be wired-in. So we just remove them all.
      Updates haddock submodule.
      Test Plan: `./validate` and `make slowtest TEST=tc198`
      Reviewers: simonpj, goldfire, austin, hvr, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: goldfire, thomie
      Projects: #ghc
      Differential Revision: https://phabricator.haskell.org/D1739
      GHC Trac Issues: #11331
  35. 16 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix a number of subtle solver bugs · 9308c736
      Simon Peyton Jones authored
      As a result of some other unrelated changes I found that
      IndTypesPerf was failing, and opened Trac #11408.  There's
      a test in indexed-types/should-compile/T11408.
      The bug was that a type like
       forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int
      is in fact unambiguous, but it's a bit subtle to prove
      that it is unambiguous.
      In investigating, Dimitrios and I found several subtle
      bugs in the constraint solver, fixed by this patch
      * canRewrite was missing a Derived/Derived case.  This was
        lost by accident in Richard's big kind-equality patch.
      * Interact.interactTyVarEq would discard [D] a ~ ty if there
        was a [W] a ~ ty in the inert set.  But that is wrong because
        the former can rewrite things that the latter cannot.
        Fix: a new function eqCanDischarge
      * In TcSMonad.addInertEq, the process was outright wrong for
        a Given/Wanted in the (GWModel) case.  We were adding a new
        Derived without kicking out things that it could rewrite.
        Now the code is simpler (no special GWModel case), and works
      * The special case in kickOutRewritable for [W] fsk ~ ty,
        turns out not to be needed.  (We emit a [D] fsk ~ ty which
        will do the job.
      I improved comments and documentation, esp in TcSMonad.
  36. 07 Jan, 2016 1 commit