1. 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
      fffe3a25
  2. 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
      82538f65
  3. 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
      
        -Wsimplifiable-class-constraints
      
      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
      warnings.mk.
      
      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.
      9421b0c7
  4. 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
      928d7473
  5. 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
      7407a66d
  6. 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]
      35d37ff8
  7. 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.
      d8c64e86
  8. 08 Feb, 2016 1 commit
  9. 22 Jan, 2016 1 commit
  10. 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
  11. 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
    • 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
      a7b751db
  12. 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
        correctly.
      
      * 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.
      9308c736
  13. 07 Jan, 2016 1 commit
  14. 16 Dec, 2015 1 commit
  15. 15 Dec, 2015 2 commits
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      This patch fulfils the request in Trac #11067, #10318, and #10592,
      by lifting the conservative restrictions on superclass constraints.
      
      These restrictions are there (and have been since Haskell was born) to
      ensure that the transitive superclasses of a class constraint is a finite
      set.  However (a) this restriction is conservative, and can be annoying
      when there really is no recursion, and (b) sometimes genuinely recursive
      superclasses are useful (see the tickets).
      
      Dimitrios and I worked out that there is actually a relatively simple way
      to do the job. It’s described in some detail in
      
         Note [The superclass story] in TcCanonical
         Note [Expanding superclasses] in TcType
      
      In brief, the idea is to expand superclasses only finitely, but to
      iterate (using a loop that already existed) if there are more
      superclasses to explore.
      
      Other small things
      
      - I improved grouping of error messages a bit in TcErrors
      
      - I re-centred the haddock.compiler test, which was at 9.8%
        above the norm, and which this patch pushed slightly over
      6eabb6dd
  16. 12 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
  17. 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
  18. 18 Nov, 2015 1 commit
  19. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  20. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  21. 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
  22. 11 Sep, 2015 1 commit
    • Simon Peyton Jones's avatar
      A CFunEqCan can be Derived · a7f69097
      Simon Peyton Jones authored
      This fixes the ASSERTION failures in
        indexed-types/should_fail/T5439
        typecheck/should_fail/T5490
      when GHC is compiled with -DDEBUG
      
      See Phab:D202 attached to Trac #6018
      a7f69097
  23. 03 Sep, 2015 1 commit
  24. 02 Sep, 2015 1 commit
    • Eric Seidel's avatar
      Use IP based CallStack in error and undefined · 6740d70d
      Eric Seidel authored
      This patch modifies `error`, `undefined`, and `assertError` to use
      implicit call-stacks to provide better error messages to users.
      
      There are a few knock-on effects:
      
      - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
        types for `error` and `undefined`.
      
      - `TysPrim.tyVarList` has been replaced with a new function
        `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
        subtle bugs when you need tyvars of different kinds. The naive
      
        ```
        tv1 = head $ tyVarList kind1
        tv2 = head $ tyVarList kind2
        ```
      
        would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
        would be applied incorrectly, treating `tv1` and `tv2` as the same
        tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
        and producing a single tyvar of each kind.
      
      - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
        ghc-prim.
      
      - The type `GHC.Exception.ErrorCall` has a new constructor
        `ErrorCallWithLocation` that takes two `String`s instead of one, the
        2nd one being arbitrary metadata about the error (but usually the
        call-stack). A bi-directional pattern synonym `ErrorCall` continues to
        provide the old API.
      
      Updates Cabal, array, and haddock submodules.
      
      Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
      liyang, bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D861
      
      GHC Trac Issues: #5273
      6740d70d
  25. 31 Jul, 2015 1 commit
  26. 21 Jul, 2015 1 commit
  27. 26 Jun, 2015 1 commit
  28. 21 Jun, 2015 1 commit
  29. 16 Jun, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Decompose wanted repr. eqs. when no matchable givens. · ff82387d
      eir@cis.upenn.edu authored
      This is pursuant to a conversion with SPJ, where we agreed that
      the logic behind Note [Instance and Given overlap] in TcInteract
      applied to newtype decomposition for representational equality.
      
      There is no bug report or test case, as tickling this kind of thing
      is quite hard to do!
      ff82387d
  30. 15 Jun, 2015 1 commit
  31. 11 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Another major improvement of "improvement" · ddbb97d0
      Simon Peyton Jones authored
      I wasn't very happy with my fix to Trac #10009. This is much better.
      
      The main idea is that the inert set now contains a "model", which
      embodies *all* the (nominal) equalities that we know about, with
      a view to exposing unifications.  This requires a lot fewer iterations
      of the solver than before.
      
      There are extensive comments in
       TcSMonad:  Note [inert_model: the inert model]
                  Note [Adding an inert canonical constraint the InertCans]
      
      The big changes are
      
        * New inert_model field in InertCans
      
        * Functions addInertEq, addInertCan deal with adding a
          constraint, maintaining the model
      
        * A nice improvement is that unification variables can
          unify with fmvs, so that from, say   alpha ~ fmv
          we get              alpha := fmv
          See Note [Orientation of equalities with fmvs] in TcFlatten
          It's still not perfect, as the Note explains
      
      New flag -fconstraint-solver-iterations=n, allows us to control
      the number of constraint solver iterations, and in particular
      will flag up when it's more than a small number.
      
      Performance is generally slightly better:
      T5837 is a lot better for some reason.
      ddbb97d0
  32. 01 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Re-do superclass solving (again); fixes #10423 · 1189196c
      Simon Peyton Jones authored
      TcInstDcls.tcSuperClasses was getting increasingly baroque as a
      succession of tickets (#10423 being the latest) pointed out that
      my cunning plan was not so cunning.
      
      The big issue is how to restrict the evidence that we generate
      for superclass constraints in an instance declaration to avoid
      superclass loops.  See Note [Recursive superclasses] in TcInstDcls
      which explains the plan.
      
      The question is how to implement the plan.  The new implementation is
      much neater, and is described in Note [Solving superclass constraints]
      in TcInstDcls.
      1189196c
  33. 18 May, 2015 2 commits
    • Simon Peyton Jones's avatar
      Make the "matchable-given" check happen first · 228ddb95
      Simon Peyton Jones authored
      This change makes the matchable-given check apply uniformly to
           - constraint tuples
           - natural numbers
           - Typeable
      as well as to vanilla class constraints.
      
      See Note [Instance and Given overlap] in TcInteract
      228ddb95
    • 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
  34. 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
  35. 13 May, 2015 2 commits
    • Simon Peyton Jones's avatar
      Make the "matchable-given" check happen first · eb6ca851
      Simon Peyton Jones authored
      This change makes the matchable-given check apply uniformly to
           - constraint tuples
           - natural numbers
           - Typeable
      as well as to vanilla class constraints.
      
      See Note [Instance and Given overlap] in TcInteract
      eb6ca851
    • Simon Peyton Jones's avatar
      Two wibbles to fix the build · a154944b
      Simon Peyton Jones authored
      ...following the constraint-tuple patch.
      
      * There was interaction with the recent Safe Haskell change
      * Haddock comoplained about constraint tuples defined but not used
      a154944b