1. 16 Oct, 2017 1 commit
    • Simon Marlow's avatar
      Fix calculation in threadStackOverflow · 8adb84fe
      Simon Marlow authored
      Summary:
      The calculation was too conservative, and could result in copying zero
      frames into the new stack chunk, which caused a knock-on failure in
      the interpreter.
      
      Test Plan: Tested on an in-house repro (not shareable, unfortunately)
      
      Reviewers: niteria, bgamari, austin, erikd
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4052
      8adb84fe
  2. 15 Oct, 2017 1 commit
  3. 13 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Delete obsolete docs on GADT interacton with TypeApplications · 2be55b85
      Ryan Scott authored
      Even since ef26182e, this section of
      the users' guide is wrong, as there are no longer special rules for
      the order of type variables in GADT constructors' type signatures
      vis-à-vis visible type application. As a result, this section can
      simply be deleted, as there is no longer anything interesting to say
      about the topic.
      2be55b85
  4. 12 Oct, 2017 4 commits
    • Simon Peyton Jones's avatar
      Re-apply "Typeable: Allow App to match arrow types" · 3de788c4
      Simon Peyton Jones authored
      This re-applies
       commit cc6be3a2
        Author: Ben Gamari <bgamari.foss@gmail.com>
        Date:   Tue Sep 19 18:57:38 2017 -0400
      
          Typeable: Allow App to match arrow types
      
      which was reverted because of Trac #14270.  Now the latter is
      fixed we can re-apply it.
      
      The original ticket was Trac #14236
      3de788c4
    • Simon Peyton Jones's avatar
      Do not bind coercion variables in SpecConstr rules · fb050a33
      Simon Peyton Jones authored
      Trac #14270 showed that SpecConstr could cause nasty Lint failures
      if it generates a RULE that binds coercion varables.  See
      
       * Note [SpecConstr and casts], and
       * the test simplCore/should_compile/T14270.
      
      This doesn't feel like the final word to me, because somehow the
      specialisation "ought" to work.  So I left in a debug WARN to yell if
      the new check acutally fires.
      
      Meanwhile, it stops the erroneous specialisation.
      
      binding coercion
      fb050a33
    • Simon Peyton Jones's avatar
      Add missing T14325.stderr · 15aefb48
      Simon Peyton Jones authored
      15aefb48
    • Simon Peyton Jones's avatar
      Do not quantify over deriving clauses · 82b77ec3
      Simon Peyton Jones authored
      Trac #14331 showed that in a data type decl like
      
         data D = D deriving (C (a :: k))
      
      we were quantifying D over the 'k' in the deriving clause.  Yikes.
      
      Easily fixed, by deleting code in RnTypes.extractDataDefnKindVars
      
      See the discussion on the ticket, esp comment:8.
      82b77ec3
  5. 11 Oct, 2017 11 commits
  6. 10 Oct, 2017 1 commit
    • Tamar Christina's avatar
      Split SysTools up some · e51e565d
      Tamar Christina authored
      Summary:
      SysTools and DriverTools have an annoying mutual dependency.
      They also each contain pieces of the linker. In order for
      changes to be shared between the library and the exe linking
      code this dependency needs to be broken in order to avoid
      using hs-boot files.
      
      Reviewers: austin, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4071
      e51e565d
  7. 07 Oct, 2017 3 commits
    • Ryan Scott's avatar
      Simply Data instance context for AmbiguousFieldOcc · f337a208
      Ryan Scott authored
      The current, verbose instance context can be compacted into
      `DataId pass`. Indeed, that's what most of the `Data` instances
      in this module already do, so this just makes things consistent.
      f337a208
    • Ryan Scott's avatar
      Fix #14320 by looking through HsParTy in more places · f1d2db68
      Ryan Scott authored
      Summary:
      GHC was needlessly rejecting GADT constructors' type
      signatures that were surrounded in parentheses due to the fact that
      `splitLHsForAllTy` and `splitLHsQualTy` (which are used to check as
      part of checking if GADT constructor return types are correct)
      weren't looking through parentheses (i.e., `HsParTy`). This is
      easily fixed, though.
      
      Test Plan: make test TEST=T14320
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14320
      
      Differential Revision: https://phabricator.haskell.org/D4072
      f1d2db68
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      Summary:
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      
      Along the way, I:
      
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
        this.
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      
      Test Plan: make test TEST=T11721_TH
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: goldfire, bgamari, simonpj
      
      Subscribers: rwbarton, thomie, simonpj
      
      GHC Trac Issues: #11721
      
      Differential Revision: https://phabricator.haskell.org/D4070
      341d3a78
  8. 06 Oct, 2017 1 commit
  9. 05 Oct, 2017 2 commits
  10. 04 Oct, 2017 2 commits
  11. 03 Oct, 2017 13 commits
    • Ben Gamari's avatar
      user-guide: Mention COMPLETE pragma in release notes · 3201d85f
      Ben Gamari authored
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14305
      
      Differential Revision: https://phabricator.haskell.org/D4059
      3201d85f
    • Ben Gamari's avatar
      base: Remove deprecated Chan combinators · 361af628
      Ben Gamari authored
      Removes isEmptyChan and unGetChan, which have been deprecated for a very
      long time. See #13561.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13561
      
      Differential Revision: https://phabricator.haskell.org/D4060
      361af628
    • Douglas Wilson's avatar
      Don't pass HscEnv to functions in the Hsc monad · 4899a86b
      Douglas Wilson authored
      `Hsc` is a reader monad in `HscEnv`. Several functions in HscMain were
      taking parameters of type `HscEnv` or `DynFlags`, and returning values
      of type `Hsc a`. This patch removes those parameters in favour of asking
      them from the context.
      
      This removes a source of confusion and should make refactoring a bit
      easier.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4061
      4899a86b
    • Edward Z. Yang's avatar
      Include libraries which fill holes as deps when linking. · f3f624ae
      Edward Z. Yang authored
      Fixes the issue reported at https://github.com/haskell/cabal/issues/4755
      
      
      and fixes #14304 in the GHC tracker.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14304
      
      Differential Revision: https://phabricator.haskell.org/D4057
      f3f624ae
    • Moritz Angermann's avatar
      genapply: Explicitly specify arguments · de1b802b
      Moritz Angermann authored
      We seem to not be feeding either live registers or the arguments when
      generating the fast call in genapply.  This results in strange signature
      missmatches between the callee (expecting no registers) and the call
      site, expecting to pass registers.
      
      Test Plan: validate
      
      Reviewers: bgamari, simonmar, austin
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4029
      de1b802b
    • Ben Gamari's avatar
      base: Add missing @since annotations in GHC.TypeNats · 377d5a26
      Ben Gamari authored
      [skip ci]
      377d5a26
    • Iavor S. Diatchki's avatar
      Implement Div, Mod, and Log for type-level nats. · fa8035e3
      Iavor S. Diatchki authored
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, dfeuer, adamgundry, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4002
      fa8035e3
    • Ryan Scott's avatar
      Track the order of user-written tyvars in DataCon · ef26182e
      Ryan Scott authored
      After typechecking a data constructor's type signature, its type
      variables are partitioned into two distinct groups: the universally
      quantified type variables and the existentially quantified type
      variables. Then, when prompted for the type of the data constructor,
      GHC gives this:
      
      ```lang=haskell
      MkT :: forall <univs> <exis>. (...)
      ```
      
      For H98-style datatypes, this is a fine thing to do. But for GADTs,
      this can sometimes produce undesired results with respect to
      `TypeApplications`. For instance, consider this datatype:
      
      ```lang=haskell
      data T a where
        MkT :: forall b a. b -> T a
      ```
      
      Here, the user clearly intended to have `b` be available for visible
      type application before `a`. That is, the user would expect
      `MkT @Int @Char` to be of type `Int -> T Char`, //not//
      `Char -> T Int`. But alas, up until now that was not how GHC
      operated—regardless of the order in which the user actually wrote
      the tyvars, GHC would give `MkT` the type:
      
      ```lang=haskell
      MkT :: forall a b. b -> T a
      ```
      
      Since `a` is universal and `b` is existential. This makes predicting
      what order to use for `TypeApplications` quite annoying, as
      demonstrated in #11721 and #13848.
      
      This patch cures the problem by tracking more carefully the order in
      which a user writes type variables in data constructor type
      signatures, either explicitly (with a `forall`) or implicitly
      (without a `forall`, in which case the order is inferred). This is
      accomplished by adding a new field `dcUserTyVars` to `DataCon`, which
      is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to
      the order in which the user wrote them. For more details, refer to
      `Note [DataCon user type variables]` in `DataCon.hs`.
      
      An interesting consequence of this design is that more data
      constructors require wrappers. This is because the workers always
      expect the first arguments to be the universal tyvars followed by the
      existential tyvars, so when the user writes the tyvars in a different
      order, a wrapper type is needed to swizzle the tyvars around to match
      the order that the worker expects. For more details, refer to
      `Note [Data con wrappers and GADT syntax]` in `MkId.hs`.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: ezyang, goldfire, rwbarton, thomie
      
      GHC Trac Issues: #11721, #13848
      
      Differential Revision: https://phabricator.haskell.org/D3687
      ef26182e
    • Tamar Christina's avatar
      Optimize linker by minimizing calls to tryGCC to avoid fork/exec overhead. · 8d647450
      Tamar Christina authored
      On Windows process creations are fairly expensive. As such calling them in
      what's essentially a hot loop is also fairly expensive.
      
      Each time we make a call to `tryGCC` the following fork/exec/wait happen
      
      ```
      gcc -> realgcc -> cc1
      ```
      
      This is very problematic, because according to the profiler about 20% of the
      time is spent on just process creation and spin time.
      
      The goal of the patch is to mitigate this by asking GCC once for it's search
      directories, caching these (because it's very hard to change these at all
      after the process started since GCC's base dirs don't change unless with
      extra supplied `-B` flags.).
      
      We also do the same for the `findSysDll` function, since this computes
      the search path every time by registery accesses etc.
      
      These changes and D3909 drop GHC on Windows startup time from 2-3s to 0.5s.
      
      The remaining issue is a 1.5s wait lock on `CONIN$` which can be addressed
      with the new I/O manager code. But this makes GHCi as responsive on Windows as
      GHC 7.8 was.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3910
      8d647450
    • Tamar Christina's avatar
      Add ability to produce crash dumps on Windows · ec9ac20d
      Tamar Christina authored
      It's often hard to debug things like segfaults on Windows,
      mostly because gdb isn't always of use and users don't know
      how to effectively use it.
      
      This patch provides a way to create a crash drump by passing
      
      `+RTS --generate-crash-dumps` as an option. If any unhandled
      exception is triggered a dump is made that contains enough
      information to be able to diagnose things successfully.
      
      Currently the created dumps are a bit big because I include
      all registers, code and threads information.
      
      This looks like
      
      ```
      $ testsuite/tests/rts/derefnull.run/derefnull.exe +RTS
      --generate-crash-dumps
      
      Access violation in generated code when reading 0000000000000000
      Crash dump created. Dump written to:
              E:\msys64\tmp\ghc-20170901-220250-11216-16628.dmp
      ```
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3912
      ec9ac20d
    • Herbert Valerio Riedel's avatar
      Sync base/changelog.md · 55001c0c
      Herbert Valerio Riedel authored
      This updates the base-4.10.0.0 entry heading which has diverged from
      
       http://hackage.haskell.org/package/base-4.10.0.0/src/changelog.md
      
      and while at it also sets the GHC version for the base-4.11 entry to
      avoid confusion about what GHC 8.2.2's base is going to include.
      
      [skip ci]
      55001c0c
    • Joachim Breitner's avatar
      Revert installing texinfo in CI systems · a36eea1a
      Joachim Breitner authored
      This reverts commit 00ff0235.
      This reverts commit 11a59de2.
      a36eea1a
    • Ryan Scott's avatar
      Add regression test for #9725 · a02039c7
      Ryan Scott authored
      Kind equalities saves the day!
      a02039c7