1. 09 Jan, 2016 1 commit
  2. 08 Jan, 2016 1 commit
    • Ryan Scott's avatar
      Fix Template Haskell's handling of infix GADT constructors · 01634277
      Ryan Scott authored
      This is the second (and hopefully last) fix needed to make TH handle
      GADTs properly (after D1465). This Diff addresses some issues with infix
      GADT constructors, specifically:
      
      * Before, you could not determine if a GADT constructor was declared
        infix because TH did not give you the ability to determine if there is
        a //user-specified// fixity declaration for that constructor. The
        return type of `reifyFixity` was changed to `Maybe Fixity` so that it
        yields `Just` the fixity is there is a fixity declaration, and
        `Nothing` otherwise (indicating it has `defaultFixity`).
      * `DsMeta`/`Convert` were changed so that infix GADT constructors are
        turned into `GadtC`, not `InfixC` (which should be reserved for
        Haskell98 datatype declarations).
      * Some minor fixes to the TH pretty-printer so that infix GADT
        constructors will be parenthesized in GADT signatures.
      
      Fixes #11345.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1744
      
      GHC Trac Issues: #11345
      01634277
  3. 06 Jan, 2016 1 commit
  4. 03 Jan, 2016 1 commit
  5. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  6. 26 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11287. · da69358b
      eir@cis.upenn.edu authored
      Happily, the fix is simply deleting some old code. I love it when
      that happens.
      da69358b
  7. 25 Dec, 2015 1 commit
  8. 24 Dec, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
    • thomie's avatar
      Don't drop last char of file if -osuf contains dot · 48db13d2
      thomie authored
      Given:
       * `file = "foo.a.b"`
       * `osuf = ".a.b"`  -- Note the initial dot.
       * `new_osuf = "c"`
      
      Before (bad, the last character of the filename is dropped):
        `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"`
      After (good):
        `stripExtension osuf file <.> new_osuf` == "foo.c"
      
      This regression was introduced in commit c489af73 (#5554). That commit
      fixed a similar but different bug, and care has been taken to not
      reintroduce it (using the the newly introduced
      `System.Filepath.stripExtension`).
      
      Given:
       * `file = "foo.a.b"`
       * `osuf = "a.b"`
       * `new_osuf = "c"`
      
      Before c489af73 (bad, the full suffix should get replaced):
        `replaceExtension file new_osuf == "foo.a.c"`
      After c489af73 (good):
        `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"`
      After this commit (still good):
        `stripExtension osuf file <.> new_osuf == "foo.c"`
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1692
      
      GHC Trac Issues: #9760
      48db13d2
  9. 23 Dec, 2015 2 commits
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored
      This introduces "freezing," an operation which prevents further
      locations from being appended to a CallStack.  Library authors may want
      to prevent CallStacks from exposing implementation details, as a matter
      of hygiene. For example, in
      
      ```
      head [] = error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      including the call-site of `error` in `head` is not strictly necessary
      as the error message already specifies clearly where the error came
      from.
      
      So we add a function `freezeCallStack` that wraps an existing CallStack,
      preventing further call-sites from being pushed onto it. In other words,
      
      ```
      pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
      ```
      
      Now we can define `head` to not produce a CallStack at all
      
      ```
      head [] =
        let ?callStack = freezeCallStack emptyCallStack
        in error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      ---
      
      1. We add the `freezeCallStack` and `emptyCallStack` and update the
         definition of `CallStack` to support this functionality.
      
      2. We add `errorWithoutStackTrace`, a variant of `error` that does not
         produce a stack trace, using this feature. I think this is a sensible
         wrapper function to provide in case users want it.
      
      3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
         rationale is that base does not export any functions that use CallStacks
         (except for `error` and `undefined`) so there's no way for the stack
         traces (from Implicit CallStacks) to include user-defined functions.
         They'll only contain the call to `error` itself. As base already has a
         good habit of providing useful error messages that name the triggering
         function, the stack trace really just adds noise to the error. (I don't
         have a strong opinion on whether we should include this third commit,
         but the change was very mechanical so I thought I'd include it anyway in
         case there's interest)
      
      4. Updates tests in `array` and `stm` submodules
      
      Test Plan: ./validate, new test is T11049
      
      Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1628
      
      GHC Trac Issues: #11049
      380b25ea
    • Erik de Castro Lopo's avatar
      Delete incorrect *-ws-32 expected test output · dab8e34d
      Erik de Castro Lopo authored
      Summary:
      The *-ws-32 file were too difficult to keep up-to-date so @bgamari
      updated the test outut normalization code in commit 786d528e
      to make these files un-necessary.
      
      Test Plan: test on PowerPC
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1690
      dab8e34d
  10. 22 Dec, 2015 1 commit
    • Ryan Scott's avatar
      Rework Template Haskell's handling of strictness · f975b0b1
      Ryan Scott authored
      Currently, Template Haskell's treatment of strictness is not enough to
      cover all possible combinations of unpackedness and strictness. In
      addition, it isn't equipped to deal with new features (such as
      `-XStrictData`) which can change a datatype's fields' strictness during
      compilation.
      
      To address this, I replaced TH's `Strict` datatype with
      `SourceUnpackedness` and `SourceStrictness` (which give the programmer a
      more complete toolkit to configure a datatype field's strictness than
      just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
      reify a constructor fields' strictness post-compilation through the
      `reifyConStrictness` function.
      
      Fixes #10697.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1603
      
      GHC Trac Issues: #10697
      f975b0b1
  11. 21 Dec, 2015 1 commit
  12. 20 Dec, 2015 1 commit
  13. 17 Dec, 2015 3 commits
    • Herbert Valerio Riedel's avatar
      Update containers submodule to v0.5.7.0 release · c5c72aaf
      Herbert Valerio Riedel authored
      This is the designated release to go with GHC 8.0.1
      
      This release doesn't need any warning-suppression flags anymore, so
      remove those from mk/warnings.mk
      
      /cc @foxik
      c5c72aaf
    • Simon Marlow's avatar
      accept output · a6d664cf
      Simon Marlow authored
      a6d664cf
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  14. 15 Dec, 2015 3 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
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
    • Erik de Castro Lopo's avatar
      Update expected test output for 32 bit platforms · 4c9d1eab
      Erik de Castro Lopo authored
      Test Plan: Run tests on a 32 bit platform
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1627
      4c9d1eab
  15. 14 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Use Cxt for deriving clauses in TH (#10819) · 04ab55d9
      Ben Gamari authored
      Summary:
      Deriving clauses in the TH representations of data, newtype, data
      instance, and newtype instance declarations previously were just [Name],
      which didn't allow for more complex derived classes, eg. multi-parameter
      typeclasses.
      
      This switches out [Name] for Cxt, representing the derived classes as
      types instead of names.
      
      Test Plan: validate
      
      Reviewers: goldfire, spinda, austin
      
      Reviewed By: goldfire, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1202
      
      GHC Trac Issues: #10819
      04ab55d9
  16. 12 Dec, 2015 2 commits
    • johnleo's avatar
      Refactor type families in Template Haskell · 9934819f
      johnleo authored
      Fixes #10902.
      
      Test Plan: validate
      
      Reviewers: goldfire, austin, hvr, jstolarek, bgamari
      
      Reviewed By: jstolarek, bgamari
      
      Subscribers: hvr, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1570
      
      GHC Trac Issues: #10902
      9934819f
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
  17. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  18. 03 Dec, 2015 1 commit
  19. 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
  20. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      
      Highlights:
      
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
        TcTyClsDecls.checkValidTyCl.
      
      There was a lot of associated simplification all round
      924f8517
  21. 24 Nov, 2015 1 commit
    • elaforge's avatar
      Rearrange error msgs and add section markers (Trac #11014). · c05fddde
      elaforge authored
      This puts the "Relevant bindings" section at the end.
      
      It uses a TcErrors.Report Monoid to divide messages by importance and
      then mappends them together.  This is not the most efficient way since
      there are various intermediate Reports and list appends, but it probably
      doesn't matter since error messages shouldn't get that large, and are
      usually prepended.  In practice, everything is `important` except
      `relevantBindings`, which is `supplementary`.
      
      ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc,
      which has important, context, and suppelementary fields.  Each of those
      three sections is marked with a bullet character, '•' on unicode
      terminals and '*' on ascii terminals.  Since this breaks tons of tests,
      I also modified testlib.normalise_errmsg to strip out '•'s.
      
      --- Additional notes:
      
      To avoid prepending * to an empty doc, I needed to filter empty docs.
      This seemed less error-prone than trying to modify everyone who produces
      SDoc to instead produce Maybe SDoc.  So I added `Outputable.isEmpty`.
      Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise
      I think I'd need another Empty case for SDoc, and then it couldn't be a
      newtype any more.
      
      ErrMsg's errMsgShortString is only used by the Show instance, which is
      in turn only used by Show HscTypes.SourceError, which is in turn only
      needed for the Exception instance.  So it's probably possible to get rid
      of errMsgShortString, but that would a be an unrelated cleanup.
      
      Fixes #11014.
      
      Test Plan: see above
      
      Reviewers: austin, simonpj, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: simonpj, nomeata, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1427
      
      GHC Trac Issues: #11014
      c05fddde
  22. 22 Nov, 2015 1 commit
  23. 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
  24. 13 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make 'error' include the CCS call stack when profiled · 8988be85
      Simon Marlow authored
      Summary:
      The idea here is that this gives a more detailed stack trace in two
      cases:
      
      1. With `-prof` and `-fprof-auto`
      2. In GHCi (see #11047)
      
      Example, with an error inserted in nofib/shootout/binary-trees:
      
      ```
      $ ./Main 3
      Main: z
      CallStack (from ImplicitParams):
        error, called at Main.hs:67:29 in main:Main
      CallStack (from -prof):
        Main.check' (Main.hs:(67,1)-(68,82))
        Main.check (Main.hs:63:1-21)
        Main.stretch (Main.hs:32:35-57)
        Main.main.c (Main.hs:32:9-57)
        Main.main (Main.hs:(27,1)-(43,42))
        Main.CAF (<entire-module>)
      ```
      
      This doesn't quite obsolete +RTS -xc, which also attempts to display
      more information in the case when the error is in a CAF, but I'm
      exploring other solutions to that.
      
      Includes submodule updates.
      
      Test Plan: validate
      
      Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1426
      8988be85
  25. 07 Nov, 2015 2 commits
    • johnleo's avatar
      fix #10734 by adding braces to pretty-printing of let inside do · be885857
      johnleo authored
      Test Plan: validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1448
      
      GHC Trac Issues: #10734
      be885857
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  26. 01 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Bump ghc-prim version to 0.5.0.0 (closes #11043) · 84bf1eba
      Herbert Valerio Riedel authored
      This also needs to update the primitive/vector submodules in order to
      relax upper bounds on ghc-prim.
      
      Like in f8ba4b55, a mass-rewrite in testsuite/ via
      
        sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')
      
      was performed.
      84bf1eba
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.9.0.0 (closes #11026) · f8ba4b55
      Herbert Valerio Riedel authored
      This also relaxes a few upper bounds on base in the ghc.git repo;
      
      This required a mass-rewrite in testsuite/
      
        sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
      
      because it turns out the testsuite is still sensitive to package version
      changes.
      f8ba4b55
  27. 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
  28. 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
  29. 20 Oct, 2015 1 commit
    • Jan Stolarek's avatar
      Reject top-level typed TH splices. Fixes #10945 · 1750ebc2
      Jan Stolarek authored
      When TemplateHaskell language extension is enabled it is valid to have
      top-level expressions.  Each such expression is treated as a contents
      of a splice.  The problem arises with typed splices.  They are not valid
      at the top level and therefore we should interpret them not as a splice
      but as a top-level expression (aka. implicit splice).  So saying:
      
      $$foo
      
      is equivalent of:
      
      $( $$foo )
      
      This patch makes sure that this is indeed the case.  Until now we
      incorrectly treated typed splices as explicit splices.
      1750ebc2
  30. 16 Oct, 2015 1 commit