1. 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
  2. 09 Dec, 2015 2 commits
  3. 07 Dec, 2015 1 commit
  4. 04 Dec, 2015 3 commits
  5. 03 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Major Overhaul of Pattern Match Checking (Fixes #595) · 8a506104
      Georgios Karachalias authored
      This patch adresses several problems concerned with exhaustiveness and
      redundancy checking of pattern matching. The list of improvements includes:
      
      * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
        This fixes #4139, #3927, #8970 and other related tickets.
      
      * Making the check laziness-aware. Cases that are overlapped but affect
        evaluation are issued now with "Patterns have inaccessible right hand side".
        Additionally, "Patterns are overlapped" is now replaced by "Patterns are
        redundant".
      
      * Improved messages for literals. This addresses tickets #5724, #2204, etc.
      
      * Improved reasoning concerning cases where simple and overloaded
        patterns are matched (See #322).
      
      * Substantially improved reasoning for pattern guards. Addresses #3078.
      
      * OverloadedLists extension does not break exhaustiveness checking anymore
        (addresses #9951). Note that in general this cannot be handled but if we know
        that an argument has type '[a]', we treat it as a list since, the instance of
        'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
        not clear or is not the list type, then the check cannot do much still. I am
        a bit concerned about OverlappingInstances though, since one may override the
        '[a]' instance with e.g. an '[Int]' instance that is not the identity.
      
      * Improved reasoning for nested pattern matching (partial solution). Now we
        propagate type and (some) term constraints deeper when checking, so we can
        detect more inconsistencies. For example, this is needed for #4139.
      
      I am still not satisfied with several things but I would like to address at
      least the following before the next release:
          Term constraints are too many and not printed for non-exhaustive matches
      (with the exception of literals). This sometimes results in two identical (in
      appearance) uncovered warnings. Unless we actually show their difference, I
      would like to have a single warning.
      8a506104
  6. 02 Dec, 2015 1 commit
  7. 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
  8. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      
      Highlights:
      
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
        TcTyClsDecls.checkValidTyCl.
      
      There was a lot of associated simplification all round
      924f8517
  9. 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
  10. 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
  11. 17 Nov, 2015 1 commit
    • quchen's avatar
      MonadFail proposal, phase 1 · 233d1312
      quchen authored
      This implements phase 1 of the MonadFail proposal (MFP, #10751).
      
      - MonadFail warnings are all issued as desired, tunable with two new flags
      - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings`
        (but it's disabled by default right now)
      
      Credits/thanks to
      - Franz Thoma, whose help was crucial to implementing this
      - My employer TNG Technology Consulting GmbH for partially funding us
        for this work
      
      Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma
      
      Reviewed By: hvr, bgamari, fmthoma
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1248
      
      GHC Trac Issues: #10751
      233d1312
  12. 16 Nov, 2015 1 commit
  13. 11 Nov, 2015 1 commit
  14. 30 Oct, 2015 2 commits
    • 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
    • Ben Gamari's avatar
      Unify: Add Outputable instance for UnifyResultM · 56f9ef41
      Ben Gamari authored
      Reviewers: simonpj, austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1389
      56f9ef41
  15. 29 Oct, 2015 3 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
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
  16. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  17. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  18. 08 Oct, 2015 1 commit
  19. 21 Sep, 2015 2 commits
    • 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
    • eir@cis.upenn.edu's avatar
      Perform a validity check on assoc type defaults. · e27b267f
      eir@cis.upenn.edu authored
      This fixes #10817 and #10899. A knock-on effect is that we must
      now remember locations of associated type defaults for error
      messages during validity checking. This isn't too bad, but it
      increases the size of the diff somewhat.
      
      Test cases: indexed-types/should_fail/T108{17,99}
      e27b267f
  20. 19 Sep, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10815 by kind-checking type patterns against known kinds. · 2d4db40a
      eir@cis.upenn.edu authored
      tcFamTyPats now must take information about the instantiation of any
      class variables, when checking the instance of an associated type.
      
      Getting this to work out required some unexpected refactoring in
      TcDeriv. TcDeriv needs to look at class instances because of the
      possibility of associated datatypes with `deriving` specs. TcDeriv
      worked over the user-specified instances. But any data family instances
      were already processed, and TcDeriv had no way of finding the rep
      tycons. Indeed, TcDeriv *re-type-checked* any data family instances
      in an attempt to rediscover what GHC already knew. So, this commit
      introduces better tracking of compiled data families between TcInstDcls
      and TcDeriv to streamline all of this.
      2d4db40a
  21. 11 Sep, 2015 2 commits
  22. 03 Sep, 2015 1 commit
  23. 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
  24. 18 Aug, 2015 1 commit
  25. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Tidy up and refactor wildcard handling · 95364812
      Simon Peyton Jones authored
      When examining #10615, I found the wildcard handling hard
      to understand.  This patch refactors quite a bit, but with
      no real change in behaviour.
      
       * Split out TcIdSigInfo from TcSigInfo, as a separate type,
         like TcPatSynInfo.
      
       * Make TcIdSigInfo express more invariants by pushing the
         wildard info into TcIdSigBndr
      
       * Remove all special treatment of unification variables that arise
         from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
         argument.
      
      A ton of konck on changes.  The result is significantly simpler, I think.
      95364812
  26. 04 Aug, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10713. · f063bd54
      eir@cis.upenn.edu authored
      When doing the apartness/flattening thing, we really only need to
      eliminate non-generative tycons, not *all* families. (Data families
      are indeed generative!)
      f063bd54
  27. 02 Aug, 2015 2 commits
  28. 01 Aug, 2015 1 commit
  29. 30 Jul, 2015 1 commit
  30. 24 Jul, 2015 2 commits
    • Simon Peyton Jones's avatar
      Improve instanceCantMatch · 6e618d77
      Simon Peyton Jones authored
      When staring at instanceCantMatch I realised that it
      was returning False (safe but inefficient) when it could
      validly return True, on arguments like
         [Nothing,   Just Int]
         [Just Bool, Just Bool]
      
      This patch makes it a bit cleverer.
      6e618d77
    • Simon Peyton Jones's avatar
      Refactoring around FunDeps · d53d8089
      Simon Peyton Jones authored
      This refactoring was triggered by Trac #10675.
      
      We were using 'improveClsFD' (previously called 'checkClsFD') for
      both
        * Improvement: improving a constraint against top-level instances
        * Consistency: checking when two top-level instances are
          consistent
      
      Using the same code for both seemed attractive at the time, but
      it's just too complicated.  So I've split it:
       * Improvement: improveClsFD
       * Consistency: checkFunDeps
      
      Much clearer now!
      d53d8089