1. 16 Oct, 2017 2 commits
  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. 07 Oct, 2017 1 commit
    • 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
  5. 03 Oct, 2017 4 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
    • 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
  6. 02 Oct, 2017 2 commits
  7. 30 Sep, 2017 1 commit
  8. 26 Sep, 2017 5 commits
    • Tamar Christina's avatar
      Switch VEH to VCH and allow disabling of SEH completely. · 1421d87c
      Tamar Christina authored
      Exception handling on Windows is unfortunately a bit complicated.
      But essentially the VEH Handlers we currently have are running too
      early.
      
      This was a problem as it ran so early it also swallowed C++ exceptions
      and other software exceptions which the system could have very well
      recovered from.
      
      So instead we use a sequence of chains to for the exception handlers to
      run as late as possible. You really can't get any later than this.
      
      Please read the comment in the patch for more details.
      
      I'm also providing a switch to allow people to turn off the exception
      handling entirely. In case it does present a problem with their code.
      
      (Reverted and recommitted to fix authorship information)
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13911, #12110
      
      Differential Revision: https://phabricator.haskell.org/D3911
      1421d87c
    • Ben Gamari's avatar
      Revert "Switch VEH to VCH and allow disabling of SEH completely." · 47888fd8
      Ben Gamari authored
      Reverting to fix authorship of commit.
      
      This reverts commit 1825cbdb.
      47888fd8
    • Ben Gamari's avatar
      Switch VEH to VCH and allow disabling of SEH completely. · 1825cbdb
      Ben Gamari authored
      Exception handling on Windows is unfortunately a bit complicated.
      But essentially the VEH Handlers we currently have are running too
      early.
      
      This was a problem as it ran so early it also swallowed C++ exceptions
      and other software exceptions which the system could have very well
      recovered from.
      
      So instead we use a sequence of chains to for the exception handlers to
      run as late as possible. You really can't get any later than this.
      
      Please read the comment in the patch for more details.
      
      I'm also providing a switch to allow people to turn off the exception
      handling entirely. In case it does present a problem with their code.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13911, #12110
      
      Differential Revision: https://phabricator.haskell.org/D3911
      1825cbdb
    • Gabor Greif's avatar
      A bunch of typofixes · 7446c7f6
      Gabor Greif authored
      7446c7f6
    • Ben Gamari's avatar
      Use SIGQUIT for DWARF backtraces instead of SIGUSR2 · 9738e8b6
      Ben Gamari authored
      Reviewers: austin, erikd, simonmar
      
      Subscribers: NicolasT, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3979
      9738e8b6
  9. 25 Sep, 2017 1 commit
  10. 22 Sep, 2017 1 commit
    • Facundo Domínguez's avatar
      Implement TH addCorePlugin. · 17558690
      Facundo Domínguez authored
      This allows template-haskell code to add plugins to the compilation
      pipeline. Otherwise, the user would have to pass -fplugin=... to ghc.
      
      For now, plugin modules in the current package can't be used. This is
      because when TH runs, it is too late to let GHC know that the plugin
      modules needed to be compiled first.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: angerman, rwbarton, mboes, thomie
      
      GHC Trac Issues: #13608
      
      Differential Revision: https://phabricator.haskell.org/D3821
      17558690
  11. 19 Sep, 2017 1 commit
  12. 13 Sep, 2017 1 commit
    • David Feuer's avatar
      Simplify Data.Type.Equality.== · 4be195e7
      David Feuer authored
      Contrary to previous comments, we can calculate `==` for types
      in an extremely general fashion. The approach used here is actually
      the one mistakenly rejected as impossible. There will be some cases
      when the previous version was able to reduce and this one is not,
      particularly for types in `*` that are unknown, but known equal.
      However, the new behavior is much more uniform. Within the
      established framework of equality testing by pattern matching,
      it does a better job than the previous version.
      
      Reviewers: goldfire, austin, hvr, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3835
      4be195e7
  13. 05 Sep, 2017 3 commits
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
    • Ben Gamari's avatar
      rts: Add heap breakdown type for -hT · 24e50f98
      Ben Gamari authored
      Test Plan: Build, program with `-eventlog`, try running with `+RTS -h`
      
      Reviewers: austin, erikd, simonmar
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14096
      
      Differential Revision: https://phabricator.haskell.org/D3922
      24e50f98
    • Ben Gamari's avatar
      eventlog: Clean up profiling heap breakdown type · 822abbb1
      Ben Gamari authored
      Reviewers: austin, erikd, simonmar
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14096
      
      Differential Revision: https://phabricator.haskell.org/D3923
      822abbb1
  14. 02 Sep, 2017 2 commits
    • Ryan Scott's avatar
      Fix #14167 by using isGadtSyntaxTyCon in more places · 8e4229ab
      Ryan Scott authored
      Summary:
      Two places in GHC effectively attempt to //guess// whether a data type
      was declared using GADT syntax:
      
      1. When reifying a data type in Template Haskell
      2. When pretty-printing a data type (e.g., via `:info` in GHCi)
      
      But there's no need for heuristics here, since we have a 100% accurate way to
      determine whether a data type was declared using GADT syntax: the
      `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain
      far more accurate TH reification and pretty-printing results.
      
      This is technically a breaking change, since Template Haskell reification will
      now reify some data type constructors as `(Rec)GadtC` that it didn't before,
      and some data type constructors that were previously reified as `(Rec)GadtC`
      will no longer be reified as such. But it's a very understandable breaking
      change, since the previous behavior was simply incorrect.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14167
      
      Differential Revision: https://phabricator.haskell.org/D3901
      8e4229ab
    • Ryan Scott's avatar
      Disallow bang/lazy patterns in the RHSes of implicitly bidirectional patsyns · 5dd6b13c
      Ryan Scott authored
      Summary:
      GHC was allowing implicitly bidirectional pattern synonyms with bang
      patterns and irrefutable patterns in the RHS, like so:
      
      ```lang=haskell
      pattern StrictJust a = Just !a
      ```
      
      This has multiple problems:
      
      1. `Just !a` isn't a valid expression, so it feels strange to allow it in an
         implicitly bidirectional pattern synonym.
      2. `StrictJust` doesn't provide the strictness properties one would expect
         from a strict constructor. (One could imagine a design where the
         `StrictJust` builder infers a bang pattern for its pattern variable, but
         accomplishing this inference in a way that accounts for all possible
         patterns on the RHS, including other pattern synonyms, is somewhat
         awkward, so we do not pursue this design.)
      
      We nip these issues in the bud by simply disallowing bang/irrefutable patterns
      on the RHS.
      
      Test Plan: make test TEST="T14112 unidir"
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14112
      
      Differential Revision: https://phabricator.haskell.org/D3896
      5dd6b13c
  15. 01 Sep, 2017 1 commit
  16. 29 Aug, 2017 1 commit
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      Summary:
      This tool can be used to generate dll's for any list of object files
      given to it. It will then repartition them automatically to fit within
      a dll and generates as many dll's as needed to do this. Cyclic dependencies
      between these generated dlls are handle automatically so there is no need
      to tell it how to partition.
      
      It is also a lot more general than `dll-split` as it is able to split any
      package not just `libGHC`. It also uses a trick using GNU style import libraries
      to hide the splitting from the rest of the pipeline. Which means come linking time
      you don't need to know which dll contains what symbol or how many split dlls were
      created.
      
      The import libraries are by default created with libtool. However since libtool is BFD
      based it is very slow. So if present and detected by configure the `genlib` tool
      from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
      
      To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
      
      More detailed explaination of the process can be found here
      https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3883
      5f6a8204
  17. 26 Aug, 2017 1 commit
  18. 25 Aug, 2017 1 commit
  19. 22 Aug, 2017 3 commits
  20. 19 Aug, 2017 1 commit
    • patrickdoc's avatar
      users_guide: Convert mkUserGuidePart generation to a Sphinx extension · cf8ab1ce
      patrickdoc authored
      This removes all dependencies the users guide had on `mkUserGuidePart`.
      The generation of the flag reference table and the various pieces of the
      man page is now entirely contained within the Spinx extension
      `flags.py`. You can see the man page generation on the orphan page
      https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghc.html
      
      The extension works by collecting all of the meta-data attached to the
      `ghc-flag` directives and then formatting and displaying it at
      `flag-print` directives. There is a single printing directive that can
      be customized with two options, what format to display (table, list, or
      block of flags) and an optional category to limit the output to
      (verbosity, warnings, codegen, etc.).
      
      New display formats can be added by creating a function
      `generate_flag_xxx` (where `xxx` is a description of the format) which
      takes a list of flags and a category and returns a new `xxx`. Then just
      add a reference in the dispatch table `handlers`. That display can now
      be run by passing `:type: xxx` to the `flag-print` directive.
      
      `flags.py` contains two maps of settings that can be adjusted. The first
      is a canonical list of flag categories, and the second sets default
      categories for files.
      
      The only functionality that Sphinx could not replace was the
      `what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just
      reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx
      cannot do. As the flag is deprecated, I added the list as a static file
      which can be updated manually.
      
      Additionally, this patch updates every single documented flag with the
      data from `mkUserGuidePart` to generate the reference table.
      
      Fixes #11654 and, incidentally, #12155.
      
      Reviewers: austin, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11654, #12155
      
      Differential Revision: https://phabricator.haskell.org/D3839
      cf8ab1ce
  21. 17 Aug, 2017 6 commits