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. 30 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15385 by using addDictsDs in matchGuards · 9d388eb8
      Ryan Scott authored
      Summary:
      When coverage checking pattern-matches, we rely on the call
      sites in the desugarer to populate the local dictionaries and term
      evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns
      out that only the call site for desugaring `case` expressions was
      actually doing this properly. In another part of the desugarer,
      `matchGuards` (which handles pattern guards), it did not update the
      local dictionaries in scope at all, leading to #15385.
      
      Fixing this is relatively straightforward: just augment the
      `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`.
      Accomplishing this took a little bit of import/export tweaking:
      
      * We now need to export `collectEvVarsPat` from `HsPat.hs`.
      * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr`
        from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the
        import chain.
      
      Test Plan: make test TEST=T15385
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15385
      
      Differential Revision: https://phabricator.haskell.org/D4968
      9d388eb8
  2. 27 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Small refactor in desugar of pattern matching · 45cfe651
      Simon Peyton Jones authored
      In reviewing Phab:D4968 for Trac #15385 I saw a small
      but simple refactor to avoid unnecessary work in the
      desugarer.
      
      This patch just arranges to call
         matchSinglePatVar v ...
      rather than
         matchSinglePat (Var v) ...
      
      The more specialised function already existed, as
         match_single_pat_var
      
      I also added more comments about decideBangHood
      45cfe651
  3. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  4. 09 Apr, 2018 1 commit
  5. 15 Jan, 2018 1 commit
    • David Feuer's avatar
      Kill off irrefutable pattern errors · 492e6044
      David Feuer authored
      Distinguishing between "refutable" and "irrefutable" patterns
      (as described by the Haskell Report) in incomplete pattern errors
      was more confusing than helpful. Remove references to irrefutable
      patterns.
      
      Reviewers: hvr, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14569
      
      Differential Revision: https://phabricator.haskell.org/D4261
      492e6044
  6. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  7. 08 Nov, 2017 1 commit
  8. 07 Nov, 2017 2 commits
  9. 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
  10. 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
  11. 27 Jun, 2017 1 commit
  12. 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
  13. 17 Mar, 2017 1 commit
    • 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
  14. 01 Feb, 2017 1 commit
  15. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  16. 05 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Ensure nested binders have Internal Names · baf9ebe5
      Simon Peyton Jones authored
      This is a long-standing bug.  A nested (non-top-level) binder
      in Core should not have an External Name, like M.x. But
      
      - Lint was not checking this invariant
      
      - The desugarer could generate programs that failed the
        invariant.  An example is in
        tests/deSugar/should_compile/T13043, which had
           let !_ = M.scState in ...
        This desugared to
           let ds = case M.scSate of M.scState { DEFAULT -> () }
           in case ds of () -> ...
      
        We were wrongly re-using that scrutinee as a case binder.
        And Trac #13043 showed that could ultimately lead to two
        top-level bindings with the same closure name.  Alas!
      
      - The desugarer had one other place (in DsUtils.mkCoreAppDs)
        that could generate bogus code
      
      This patch fixes all three bugs, and adds a regression test.
      baf9ebe5
  17. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix desugaring of pattern bindings (again) · 2fbfbca2
      Simon Peyton Jones authored
      This patch fixes Trac #12595.  The problem was with a
      pattern binding like
           !x = e
      For a start it's silly to match that pattern and build
      a unit tuple (the General Case of mkSelectorBinds); but
      that's what was happening because the bang fell through
      to the general case.  But for a variable pattern building
      any auxiliary bindings is stupid.  So the patch
      introduces a new case in mkSelectorBinds for variable
      patterns.
      
      Then it turned out that if 'e' was a plain variable, and
      moreover was imported GlobalId, then matchSinglePat made
      it a /bound/ variable, which should never happen.  That
      ultimately caused a linker error, but the original bug
      was much earlier.
      2fbfbca2
  18. 26 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix and refactor strict pattern bindings · e3f341f3
      Simon Peyton Jones authored
      This patch was triggered by Trac #11601, where I discovered that
      -XStrict was really not doing the right thing. In particular,
      
        f y = let !(Just x) = blah[y] in body[y,x]
      
      This was evaluating 'blah' but not pattern matching it
      against Just until x was demanded.  This is wrong.
      
      The patch implements a new semantics which ensures that strict
      patterns (i.e. ones with an explicit bang, or with -XStrict)
      are evaluated fully when bound.
      
      * There are extensive notes in DsUtils:
        Note [mkSelectorBinds]
      
      * To do this I found I need one-tuples;
        see Note [One-tuples] in TysWiredIn
      
      I updated the user manual to give the new semantics
      e3f341f3
  19. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  20. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix desugaring of bang-pattern let-bindings · 01449eb5
      Simon Peyton Jones authored
      When implementing Strict Haskell, the patch 46a03fbe didn't faithfully
      implement the semantics given in the manual. In particular there was
      an ad-hoc case in mkSelectorBinds for "strict and no binders" that
      didn't work.
      
      This patch fixes it, curing Trac #11572.
      
      Howver it forced me to think about banged let-bindings, and I rather
      think we do not have quite the right semantics yet, so I've opened
      Trac #11601.
      01449eb5
  21. 11 Feb, 2016 1 commit
  22. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  23. 15 Dec, 2015 2 commits
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
    • Simon Peyton Jones's avatar
      Comment layout only · 947e44fe
      Simon Peyton Jones authored
      947e44fe
  24. 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
  25. 22 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations: Make all RdrName occurences Located · 3df9563e
      Alan Zimmerman authored
      At the moment the API Annotations can only be used on the ParsedSource,
      as there are changes made to the RenamedSource that prevent it from
      being used to round trip source code.
      
      It is possible to build a map from every Located Name in the
      RenamedSource from its location to the Name, which can then be used when
      resolved names are required when changing the ParsedSource.
      
      However, there are instances where the identifier is not located,
      specifically
      
        (GHC.VarPat name)
        (GHC.HsVar name)
        (GHC.UserTyVar name)
        (GHC.HsTyVar name)
      
      Replace each of the name types above with (Located name)
      
      Updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1512
      
      GHC Trac Issues: #11019
      3df9563e
  26. 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
  27. 14 Nov, 2015 1 commit
  28. 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
  29. 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
  30. 17 Sep, 2015 1 commit
  31. 30 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Define DsUtils.mkCastDs and use it · 92d25672
      Simon Peyton Jones authored
      This change avoids a spurious WARNing from mkCast.  In the output of
      the desugarer (only, I think) we can have a cast where the type of the
      expression and cast don't syntactically match, because of an enclosing
      type-let binding.
      92d25672
  32. 16 Dec, 2014 1 commit
  33. 03 Dec, 2014 1 commit
  34. 21 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rejig builders for pattern synonyms, especially unlifted ones · e8762081
      Simon Peyton Jones authored
      When a pattern synonym is for an unlifted pattern, its "builder" would
      naturally be a top-level unlifted binding, which isn't allowed.  So we
      give it an extra Void# argument.
      
      Our Plan A involved then making *two* Ids for these builders, with
      some consequential fuss in the desugarer.  This was more pain than I
      liked, so I've re-jigged it.
      
       * There is just one builder for a pattern synonym.
      
       * It may have an extra Void# arg, but this decision is signalled
         by the Bool in the psBuilder field.
      
         I did the same for the psMatcher field.
      
         Both Bools are serialised into interface files, so there is
         absolutely no doubt whether that extra Void# argument is required.
      
       * I renamed "wrapper" to "builder".  We have too may "wrappers"
      
       * In order to deal with typecchecking occurrences of P in expressions,
         I refactored the tcInferId code in TcExpr.
      
      All of this allowed me to revert 5fe872
         "Apply compulsory unfoldings during desugaring, except for `seq` which is special."
      which turned out to be a rather messy hack in DsBinds
      e8762081
  35. 08 Nov, 2014 1 commit
    • cactus's avatar
      In pattern synonym matchers, support unboxed continuation results (fixes #9783). · 474e535b
      cactus authored
      This requires ensuring the continuations have arguments by adding a dummy
      Void# argument when needed. This is so that matching on a pattern synonym
      is lazy even when the result is unboxed, e.g.
      
          pattern P = ()
          f P = 0#
      
      In this case, without dummy arguments, the generated matcher's type would be
      
         $mP :: forall (r :: ?). () -> r -> r -> r
      
      which is called in `f` at type `() -> Int# -> Int# -> Int#`,
      so it would be strict, in particular, in the failure continuation
      of `patError`.
      
      We work around this by making sure both continuations have arguments:
      
        $mP :: forall (r :: ?). () -> (Void# -> r) -> (Void# -> r) -> r
      
      Of course, if `P` (and thus, the success continuation) has any arguments,
      we are only adding the extra dummy argument to the failure continuation.
      474e535b
  36. 26 Sep, 2014 1 commit
  37. 05 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix egregious instantiation bug in matchOneConLike (fixing Trac #9023) · 0a55a3ca
      Simon Peyton Jones authored
      We simply weren't giving anything like the right instantiating types
      to patSynInstArgTys in matchOneConLike.
      
      To get these instantiating types would have involved matching the
      result type of the pattern synonym with the pattern type, which is
      tiresome.  So instead I changed ConPatOut so that instead of recording
      the type of the *whole* pattern (in old field pat_ty), it not records
      the *instantiating* types (in new field pat_arg_tys).  Then we canuse
      TcHsSyn.conLikeResTy to get the pattern type when needed.
      
      There are lots of knock-on incidental effects, but they mostly made
      the code simpler, so I'm happy.
      0a55a3ca