1. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  2. 15 Mar, 2019 1 commit
  3. 24 Nov, 2018 1 commit
  4. 22 Nov, 2018 1 commit
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
      
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
      
         Fix unused-import stuff in a better way
      
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      
      This led to Trac #13064 and #15393
      
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      
      The two important changes are
      
      * Fix the bug in bestImport
      
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      
      In unravalling this I also ended up doing a few other things
      
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7
  5. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  6. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      
      Particular changes
      
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      
      * isCoercionType is renamed to isCoVarType
      
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
      
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
      
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
      
        Also see Note [Evidence for quantified constraints] in Type.
      
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
      0faf7fd3
  7. 30 Aug, 2018 1 commit
  8. 25 Jul, 2018 1 commit
  9. 04 Jul, 2018 1 commit
  10. 14 Jun, 2018 1 commit
  11. 07 Jun, 2018 1 commit
    • Ben Gamari's avatar
      Don't use unsafeGlobalDynFlags in optCoercion · 64c71ce9
      Ben Gamari authored
      This plumbs DynFlags through CoreOpt so optCoercion can finally
      eliminate its usage of `unsafeGlobalDynFlags`.
      
      Note that this doesn't completely eliminate `unsafeGlobalDynFlags`
      usage from this bit of the compiler. A few uses are introduced in
      call-sites where we don't (yet) have ready access to `DynFlags`.
      
      Test Plan: Validate
      
      Reviewers: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4774
      64c71ce9
  12. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      
      The main ticket is Trac #2893, but also relevant are
        #5927
        #8516
        #9123 (especially!  higher kinded roles)
        #14070
        #14317
      
      The wiki page is
        https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      
      Here is the relevant Note:
      
      Note [Quantified constraints]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The -XQuantifiedConstraints extension allows type-class contexts like
      this:
      
        data Rose f x = Rose x (f (Rose f x))
      
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
      
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
      
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
      
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
      
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
      
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
      
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
      
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
      
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
      
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      
      Some other related refactoring
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
        unifiers
      7df58960
  13. 21 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Remove TcType.toTcType · b7e80ae0
      Simon Peyton Jones authored
      In the olden days we insisted that only TcTyVars could appear
      in a TcType.  But now we are more accommodating; see TcType
        Note [TcTyVars and TyVars in the typechecker]
      
      This patch removes a function that converted a Type to a TcType.
      It didn't do anything useful except statisfy an invariant that
      we no longer have.  Now it's gone.
      b7e80ae0
  14. 13 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  15. 02 Mar, 2018 1 commit
  16. 26 Jan, 2018 1 commit
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      Ideally, I'd like to do
      
          type EvTerm = CoreExpr
      
      and the type checker builds the evidence terms as it goes. This failed,
      becuase the evidence for `Typeable` refers to local identifiers that are
      added *after* the typechecker solves constraints. Therefore, `EvTerm`
      stays a data type with two constructors: `EvExpr` for `CoreExpr`
      evidence, and `EvTypeable` for the others.
      
      Delted `Note [Memoising typeOf]`, its reference (and presumably
      relevance) was removed in 8fa4bf9a.
      
      Differential Revision: https://phabricator.haskell.org/D4341
      0e022e56
  17. 01 Dec, 2017 1 commit
    • David Feuer's avatar
      Cache TypeRep kinds aggressively · bc761ad9
      David Feuer authored
      Cache `TypeRep k` in each `TrApp` or `TrTyCon` constructor of
      `TypeRep (a :: k)`. This makes `typeRepKind` cheap.
      
      With this change, we won't need any special effort to deserialize
      typereps efficiently. The downside, of course, is that we make
      `TypeRep`s slightly larger.
      
      Reviewers: austin, hvr, bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: carter, simonpj, rwbarton, thomie
      
      GHC Trac Issues: #14254
      
      Differential Revision: https://phabricator.haskell.org/D4085
      bc761ad9
  18. 30 Oct, 2017 1 commit
  19. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  20. 12 Sep, 2017 1 commit
  21. 07 Sep, 2017 1 commit
  22. 29 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Small refactor of getRuntimeRep · a6c448b4
      Simon Peyton Jones authored
      Instead of using a string argument, use HasDebugCallStack.
      (Oddly, some functions were using both!)
      
      Plus, use getRuntimeRep rather than getRuntimeRep_maybe when
      if the caller panics on Nothing. Less code, and a better debug
      stack.
      a6c448b4
  23. 18 Aug, 2017 1 commit
  24. 01 Aug, 2017 1 commit
  25. 31 Jul, 2017 2 commits
    • Simon Peyton Jones's avatar
      Reject top-level banged bindings · af89d687
      Simon Peyton Jones authored
      Bizarrely, we were not rejecting
        !x = e
      
      Fix:
      
      * In the test in DsBinds.dsTopLHsBinds, use isBangedHsBind, not
        isBangedPatBind.  (Indeed the latter dies altogther.)
      
      * Implement isBangedHsBind in HsUtils;
        be sure to handle AbsBinds
      
      All this was shown up by Trac #13594
      af89d687
    • Simon Peyton Jones's avatar
      Improve the desugaring of -XStrict · 46368868
      Simon Peyton Jones authored
      Trac #14035 showed that -XStrict was generating some TERRIBLE
      desugarings, espcially for bindings with INLINE pragmas. Reason: with
      -XStrict, all AbsBinds (even for non-recursive functions) went via the
      general-case deguaring for AbsBinds, namely "generate a tuple and
      select from it", even though in this case there was only one variable
      in the tuple.  And that in turn interacts terribly badly with INLINE
      pragmas.
      
      This patch cleans things up:
      
      * I killed off AbsBindsSig completely, in favour of a boolean flag
        abs_sig in AbsBinds.  See Note [The abs_sig field of AbsBinds]
      
        This allowed me to delete lots of code; and instance-method
        declarations can enjoy the benefits too.  (They could have
        before, but no one had changed them to use AbsBindsSig.)
      
      * I refactored all the AbsBinds handling in DsBinds into a new
        function DsBinds.dsAbsBinds.  This allowed me to handle the
        strict case uniformly
      46368868
  26. 28 Jun, 2017 1 commit
  27. 27 Jun, 2017 1 commit
  28. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
  29. 09 May, 2017 1 commit
    • Ben Gamari's avatar
      Treat banged bindings as FunBinds · 37299536
      Ben Gamari authored
      This reworks the HsSyn representation to make banged variable patterns
      (e.g. !x = e) be represented as FunBinds instead of PatBinds, adding a flag to
      FunRhs to record the bang.
      
      Fixes #13594.
      
      Reviewers: austin, goldfire, alanz, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3525
      37299536
  30. 28 Apr, 2017 1 commit
  31. 17 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      No join-point from an INLINE function with wrong arity · a7dbafe9
      Simon Peyton Jones authored
      The main payload of this patch is NOT to make a join-point
      from a function with an INLINE pragma and the wrong arity;
      see Note [Join points and INLINE pragmas] in CoreOpt.
      This is what caused Trac #13413.
      
      But we must do the exact same thing in simpleOptExpr,
      which drove me to the following refactoring:
      
      * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new
        module CoreOpt along with a few others (exprIsConApp_maybe,
        pushCoArg, etc)
      
        This eliminates a module loop altogether (delete
        CoreArity.hs-boot), and stops CoreSubst getting too huge.
      
      * Rename Simplify.matchOrConvertToJoinPoint
           to joinPointBinding_maybe
        Move it to the new CoreOpt
        Use it in simpleOptExpr as well as in Simplify
      
      * Define CoreArity.joinRhsArity and use it
      a7dbafe9
    • Richard Eisenberg's avatar
      Fix #12709 by not building bad applications · dca44adb
      Richard Eisenberg authored
      In an effort to report multiple levity polymorphism errors all at
      once, the desugarer does not fail when encountering bad levity
      polymorphism. But we must be careful not to build the bad applications,
      lest they try to satisfy the let/app invariant and call
      isUnliftedType on a levity polymorphic type. This protects calls
      to mkCoreAppDs appropriately.
      
      test case: typecheck/should_fail/T12709
      dca44adb
  32. 14 Mar, 2017 1 commit
  33. 02 Mar, 2017 1 commit
    • David Feuer's avatar
      Prohibit RULES changing constructors · bc332b31
      David Feuer authored
      Previously, `RULES` like
      
      ```
      {-# RULES
      "JustNothing" forall x . Just x = Nothing
       #-}
      ```
      
      were allowed. Simon Peyton Jones say this seems to have been a
      mistake, that such rules have never been supported intentionally,
      and that he doesn't know if they can break in horrible ways.
      Furthermore, Ben Gamari and Reid Barton are considering trying to
      detect the presence of "static data" that the simplifier doesn't
      need to traverse at all. Such rules do not play well with that.
      So for now, we ban them altogether. In most cases, it's possible
      to work around the ban using hand-written wrapper functions.
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3169
      bc332b31
  34. 20 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Kill off the remaining Rec [] · 8a9b57f6
      Simon Peyton Jones authored
      The desugarer was producing an empty Rec group, which is never
      supposed to happen.  This small patch stops that happening.
      
      Next up: Lint should check.
      8a9b57f6
  35. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
  36. 14 Feb, 2017 1 commit
    • Adam Gundry's avatar
      Implement HasField constraint solving and modify OverloadedLabels · da493897
      Adam Gundry authored
      This implements automatic constraint solving for the new HasField class
      and modifies the existing OverloadedLabels extension, as described in
      the GHC proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current
      form of the proposal, it does *not* currently introduce a separate
      `OverloadedRecordFields` extension.
      
      This replaces D1687.
      
      The users guide documentation still needs to be written, but I'll do
      that after the implementation is merged, in case there are further
      design changes.
      
      Test Plan: new and modified tests in overloadedrecflds
      
      Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr
      
      Reviewed By: bgamari
      
      Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2708
      da493897
  37. 02 Feb, 2017 1 commit
  38. 23 Jan, 2017 1 commit