This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 21 Dec, 2015 1 commit
    • Ryan Scott's avatar
      Encode strictness in GHC generics metadata · ee6fba89
      Ryan Scott authored
      This augments `MetaSel` with a `Bang` field, which gives generic
      programmers access to the following information about each field
      selector:
      
      * `SourceUnpackedness`: whether a field was marked `{-# NOUNPACK #-}`,
        `{-# UNPACK #-}`, or not
      * `SourceStrictness`: whether a field was given a strictness (`!`) or
        laziness (`~`) annotation
      * `DecidedStrictness`: what strictness GHC infers for a field during
        compilation, which may be influenced by optimization levels,
        `-XStrictData`, `-funbox-strict-fields`, etc.
      
      Unlike in Phab:D1603, generics does not grant a programmer the ability
      to "splice" in metadata, so there is no issue including
      `DecidedStrictness` with `Bang` (whereas in Template Haskell, it had to
      be split off).
      
      One consequence of this is that `MetaNoSel` had to be removed, since it
      became redundant. The `NoSelector` empty data type was also removed for
      similar reasons.
      
      Fixes #10716.
      
      Test Plan: ./validate
      
      Reviewers: dreixel, goldfire, kosmikus, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1646
      
      GHC Trac Issues: #10716
      ee6fba89
  2. 16 Dec, 2015 1 commit
  3. 12 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      Frontend plugins. · a3c2a26b
      Edward Z. Yang authored
      
      
      Summary:
      Frontend plugins enable users to write plugins to replace
      GHC major modes.  E.g. instead of saying
      
          ghc --make A B C
      
      a user can now say
      
          ghc --frontend GHC.Frontend.Shake A B C
      
      which might provide an alternative implementation of a multi-module
      build.  For more details, see the manual entry.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1598
      
      GHC Trac Issues: #11194
      a3c2a26b
  4. 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
  5. 07 Dec, 2015 1 commit
  6. 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
  7. 29 Nov, 2015 1 commit
    • quchen's avatar
      Implement warnings for Semigroups as parent of Monoid · 290def72
      quchen authored
      This patch is similar to the AMP patch (#8004), which offered two
      functions:
      
        1. Warn when an instance of a class has been given, but the type does
           not have a certain superclass instance
        2. Warn when top-level definitions conflict with future Prelude names
      
      These warnings are issued as part of the new `-Wcompat` warning group.
      
      Reviewers: hvr, ekmett, austin, bgamari
      
      Reviewed By: hvr, ekmett, bgamari
      
      Subscribers: ekmett, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1539
      
      GHC Trac Issues: #11139
      290def72
  8. 24 Nov, 2015 1 commit
  9. 17 Nov, 2015 2 commits
  10. 16 Nov, 2015 1 commit
  11. 12 Nov, 2015 1 commit
  12. 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
  13. 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
  14. 27 Oct, 2015 1 commit
    • Ben Gamari's avatar
      PrelNames: Fix duplicate unique · d1ab6fc9
      Ben Gamari authored
      Previously unboundKey and fromIntegerClassOpKey were sharing a Unique
      Reassign unboundKey to `mkPreludeMiscIdUnique 158`
      d1ab6fc9
  15. 15 Oct, 2015 1 commit
  16. 03 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make GHC generics capable of handling unboxed types · 6cde981a
      Ryan Scott authored
      This adds a data family (`URec`) and six data family instances (`UAddr`,
      `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving
      Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`,
      `Float#`, `Int#`, or `Word#`, respectively. The programmer can then
      provide instances for these data family instances to provide custom
      implementations for unboxed types, similar to how derived `Eq`, `Ord`,
      and `Show` instances currently special-case unboxed types.
      
      Fixes #10868.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus
      
      Reviewed By: dreixel, kosmikus
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1239
      
      GHC Trac Issues: #10868
      6cde981a
  17. 02 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Move CallStack back to base · 74424346
      Ben Gamari authored
      CallStack requires tuples, instances of which are defined in GHC.Tuple.
      Unfortunately the change made in D757 to the `Typeable` deriving
      mechanism means that `GHC.Tuple` must import `GHC.Types` for types
      necessary to generate type representations.  This results in a cycle.
      
      Test Plan: Validate
      
      Reviewers: gridaphobe, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1298
      74424346
  18. 23 Sep, 2015 1 commit
  19. 22 Sep, 2015 1 commit
  20. 03 Sep, 2015 1 commit
  21. 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
  22. 26 Aug, 2015 2 commits
  23. 27 Jul, 2015 1 commit
  24. 16 Jul, 2015 1 commit
    • RyanGlScott's avatar
      Handle Char#, Addr# in TH quasiquoter (fixes #10620) · 2c9de9c9
      RyanGlScott authored
      DsMeta does not attempt to handle quasiquoted Char# or Addr# values,
      which causes expressions like `$([| 'a'# |])` or `$([| "abc"# |])` to
      fail
      with an `Exotic literal not (yet) handled by Template Haskell` error.
      
      To fix this, the API of `template-haskell` had to be changed so that
      `Lit`
      now has an extra constructor `CharPrimL` (a `StringPrimL` constructor
      already
      existed, but it wasn't used). In addition, `DsMeta` has to manipulate
      `CoreExpr`s directly that involve `Word8`s. In order to do this,
      `Word8` had
      to be added as a wired-in type to `TysWiredIn`.
      
      Actually converting from `HsCharPrim` and `HsStringPrim` to `CharPrimL`
      and
      `StringPrimL`, respectively, is pretty straightforward after that, since
      both `HsCharPrim` and `CharPrimL` use `Char` internally, and
      `HsStringPrim`
      uses a `ByteString` internally, which can easily be converted to
      `[Word8]`,
      which is what `StringPrimL` uses.
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1054
      
      GHC Trac Issues: #10620
      2c9de9c9
  25. 07 Jul, 2015 1 commit
  26. 21 Jun, 2015 1 commit
  27. 12 Jun, 2015 1 commit
    • Simon Marlow's avatar
      Add parseExpr and compileParsedExpr and use them in GHC API and GHCi · d20031d4
      Simon Marlow authored
      Summary:
      This commit brings following changes and fixes:
      
       * Implement parseExpr and compileParsedExpr;
       * Fix compileExpr and dynCompilerExpr, which returned `()` for empty expr;
       * Fix :def and :cmd, which didn't work if `IO` or `String` is not in scope;
       * Use GHCiMonad instead IO in :def and :cmd;
       * Clean PrelInfo: delete dead comment and duplicate entries, add assertion.
      
      See new tests for more details.
      
      Test Plan: ./validate
      
      Reviewers: austin, dterei, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D974
      
      GHC Trac Issues: #10508
      d20031d4
  28. 18 May, 2015 1 commit
    • 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
  29. 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
  30. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      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
      130e93aa
  31. 01 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Move IP, Symbol, Nat to ghc-prim · 2f6a0ac7
      Simon Peyton Jones authored
      This motivation is to declare class IP much earlier (in ghc-prim),
      so that implicit parameters (which depend on IP) is available
      to library code, notably the 'error' function.
      
      * Move class IP from base:GHC.IP
                      to ghc-prim:GHC.Classes
      * Delete module GHC.IP from base
      
      * Move types Symbol and Nat
            from base:GHC.TypeLits
            to ghc-prim:GHC.Types
      
      There was a name clash in GHC.RTS.Flags, where I renamed
      the local type Nat to RtsNat.
      2f6a0ac7
  32. 31 Mar, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Drop old integer-gmp-0.5 from GHC source tree · 995e8c1c
      Herbert Valerio Riedel authored
      This completes what c774b28f (#9281)
      started.  `integer-gmp-1.0` was added as an additional
      `libraries/integer-gmp2` folder while retaining the ability to configure
      GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability
      to easily switch between old/new `integer-gmp` for benchmark/debugging
      purposes.
      
      This commit removes the old `libraries/integer-gmp` folder and moves
      `libraries/integer-gmp2` into its place, while removing any mentions of
      "gmp2" as well as the to support two different `integer-gmp` packages in
      GHC's source-tree.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D769
      995e8c1c
  33. 07 Mar, 2015 1 commit
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      Summary:
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      
      The current implementation creates `TyCon` representations on the spot.
      
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      
      Reviewers: simonpj, simonmar, austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D652
      
      GHC Trac Issues: #9858
      b359c886
  34. 23 Feb, 2015 1 commit
  35. 05 Feb, 2015 1 commit
  36. 19 Jan, 2015 1 commit
    • Eric Seidel's avatar
      Expose source locations via Implicit Parameters of type GHC.Location.Location · c024af13
      Eric Seidel authored
      Summary:
      IPs with this type will always be solved for the current source
      location. If another IP of the same type is in scope, the two locations will be
      appended, creating a call-stack. The Location type is kept abstract so users
      cannot create them, but a Location can be turned into a list of SrcLocs, which
      correspond to individual locations in a program. Each SrcLoc contains a
      package/module/file name and start/end lines and columns.
      
      The only thing missing from the SrcLoc in my opinion is the name of the
      top-level definition it inhabits. I suspect that would also be useful, but it's
      not clear to me how to extract the current top-level binder from within the
      constraint solver. (Surely I'm just missing something here?)
      
      I made the (perhaps controversial) decision to have GHC completely ignore
      the names of Location IPs, meaning that in the following code:
      
          bar :: (?myloc :: Location) => String
          bar = foo
      
          foo :: (?loc :: Location) => String
          foo = show ?loc
      
      if I call `bar`, the resulting call-stack will include locations for
      
      1. the use of `?loc` inside `foo`,
      2. `foo`s call-site inside `bar`, and
      3. `bar`s call-site, wherever that may be.
      
      This makes Location IPs very special indeed, and I'm happy to change it if the
      dissonance is too great.
      
      I've also left out any changes to base to make use of Location IPs, since there
      were some concerns about a snowball effect. I think it would be reasonable to
      mark this as an experimental feature for now (it is!), and defer using it in
      base until we have more experience with it. It is, after all, quite easy to
      define your own version of `error`, `undefined`, etc. that use Location IPs.
      
      Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs
      
      Reviewers: austin, hvr, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, rodlogic, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D578
      
      GHC Trac Issues: #9049
      c024af13
  37. 10 Dec, 2014 1 commit