1. 28 Nov, 2017 1 commit
  2. 22 Nov, 2017 1 commit
    • Evan Rutledge Borden's avatar
      Add warn-missing-export-lists · 63e4ac37
      Evan Rutledge Borden authored
      Many industrial users have aligned around the idea that implicit exports
      are an anti-pattern. They lead to namespace pollution and byzantine
      naming schemes. They also prevent GHC's dead code analysis and create
      more obstacles to optimization. This warning allows teams/projects to
      warn on or enforce via -Werror explicit export lists.
      
      This warning also serves as a complement to warn-missing-import-lists.
      
      This was originally discussed here:
      https://github.com/ghc-proposals/ghc-proposals/pull/93
      
      Test Plan: Three new minimal tests have been added to the type checker.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4197
      63e4ac37
  3. 20 Nov, 2017 1 commit
  4. 09 Nov, 2017 1 commit
    • Tamar Christina's avatar
      Update Win32 version for GHC 8.4. · bdd2d286
      Tamar Christina authored
      Update to Win32 2.6 which is the expected version release for 8.4
      
      This involves moving Cabal forward which brings some backwards incompatible
      changes that needs various fixups.
      
      Bump a bunch of submodules
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: angerman, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D4133
      bdd2d286
  5. 07 Nov, 2017 2 commits
  6. 02 Nov, 2017 2 commits
  7. 27 Oct, 2017 1 commit
  8. 25 Oct, 2017 2 commits
  9. 22 Oct, 2017 1 commit
    • Tamar Christina's avatar
      Add stack traces on crashes on Windows · 99c61e22
      Tamar Christina authored
      Summary:
      This patch adds the ability to generate stack traces on crashes for Windows.
      When running in the interpreter this attempts to use symbol information from
      the interpreter and information we know about the loaded object files to
      resolve addresses to symbols.
      
      When running compiled it doesn't have this information and then defaults
      to using symbol information from PDB files. Which for now means only
      files compiled with ICC or MSVC will show traces compiled.
      
      But I have a future patch that may address this shortcoming.
      
      Also since I don't know how to walk a pure haskell stack, I can for now
      only show the last entry. I'm hoping to figure out how Apply.cmm works to
      be able to walk the stalk and give more entries for pure haskell code.
      
      In GHCi
      
      ```
      $ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs
      GHCi, version 8.3.20170830: http://www.haskell.org/ghc/  :? for help
      Ok, 1 module loaded.
      Prelude Main>
      Access violation in generated code when reading 0x0
      
       Attempting to reconstruct a stack trace...
      
         Frame        Code address
       * 0x77cde10    0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031
                       (base_ForeignziStorable_zdfStorableInt4_info+0x3f)
      ```
      
      and compiled
      
      ```
      Access violation in generated code when reading 0x0
      
       Attempting to reconstruct a stack trace...
      
         Frame        Code address
       * 0xf0dbd0     0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01
      ```
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3913
      99c61e22
  10. 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
  11. 03 Oct, 2017 3 commits
    • 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
  12. 02 Oct, 2017 1 commit
  13. 26 Sep, 2017 4 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
    • 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
  14. 19 Sep, 2017 1 commit
  15. 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
  16. 05 Sep, 2017 1 commit
    • 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
  17. 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
  18. 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
  19. 31 Jul, 2017 1 commit
  20. 27 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #12369 by being more flexible with data insts · 42392383
      Richard Eisenberg authored
      Previously, a data family's kind had to end in `Type`,
      and data instances had to list all the type patterns for the
      family. However, both of these restrictions were unnecessary:
      
      - A data family's kind can usefully end in a kind variable `k`.
        See examples on #12369.
      
      - A data instance need not list all patterns, much like how a
        GADT-style data declaration need not list all type parameters,
        when a kind signature is in place. This is useful, for example,
        here:
      
          data family Sing (a :: k)
          data instance Sing :: Bool -> Type where ...
      
      This patch also improved a few error messages, as some error
      plumbing had to be moved around.
      
      See new Note [Arity of data families] in FamInstEnv for more
      info.
      
      test case: indexed-types/should_compile/T12369
      42392383
  21. 08 Jul, 2017 1 commit
    • Tamar Christina's avatar
      Big-obj support for the Windows runtime linker · 81377e9e
      Tamar Christina authored
      Summary:
      The normal object file on Windows has a limit of `2^16`
      sections that can be in an object-file.
      
      The `big-obj` format raises this to `2^32` sections.
      
      The implementation is made difficult because we now need to support
      two header formats and two section formats that differ only by a single
      element size within each. The element that's different is in the middle
      of the structs and since the structs are used to map regions of memory
      directly, it means we need to know which struct it is when we do the
      mapping or pointer arithmetics.
      
      This is the final Object-Code format which Windows compilers can generate
      which we do not support yet in GHCI. All other major compilers on the platforms
      can produce it and all linkers consume it (bfd and lld).
      
      See http://tinyurl.com/bigobj
      
      This patch abstracts away retrieving the fields to functions which all take
      an struct which describes which object format is currently being parsed.
      These functions are always in-lined as they're small but would looks messy
      being copy-pasted everywhere.
      
      Test Plan:
      ./validate and new test `big-obj`
      
      ```
      Tamar@Rage MINGW64 /r
      $ gcc -c -Wa,-mbig-obj foo.c -o foo.o
      
      Tamar@Rage MINGW64 /r
      $ objdump -h foo.o
      
      foo.o:     file format pe-bigobj-x86-64
      
      Sections:
      Idx Name          Size      VMA               LMA               File off  Algn
        0 .text         00000010  0000000000000000  0000000000000000  00000128  2**4
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
        1 .data         00000000  0000000000000000  0000000000000000  00000000  2**4
                        ALLOC, LOAD, DATA
        2 .bss          00000000  0000000000000000  0000000000000000  00000000  2**4
                        ALLOC
        3 .xdata        00000008  0000000000000000  0000000000000000  00000138  2**2
                        CONTENTS, ALLOC, LOAD, READONLY, DATA
        4 .pdata        0000000c  0000000000000000  0000000000000000  00000140  2**2
                        CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
        5 .rdata$zzz    00000030  0000000000000000  0000000000000000  0000014c  2**4
                        CONTENTS, ALLOC, LOAD, READONLY, DATA
      
      Tamar@Rage MINGW64 /r
      $ echo main | ~/ghc/inplace/bin/ghc-stage2.exe --interactive bar.hs foo.o
      GHCi, version 8.3.20170430: http://www.haskell.org/ghc/  :? for help
      [1 of 1] Compiling Main             ( bar.hs, interpreted )
      Ok, modules loaded: Main.
      *Main> 17
      *Main> Leaving GHCi.
      ```
      
      Reviewers: austin, bgamari, erikd, simonmar
      
      Subscribers: awson, rwbarton, thomie, #ghc_windows_task_force
      
      GHC Trac Issues: #13815
      
      Differential Revision: https://phabricator.haskell.org/D3523
      81377e9e
  22. 07 Jul, 2017 1 commit
    • Tamar Christina's avatar
      Implement split-sections support for windows. · bd4fdc6a
      Tamar Christina authored
      Summary:
      Initial implementation of split-section on Windows.
      
      This also corrects section namings and uses the platform
      convention of `$` instead of `.` to separate sections.
      
      Implementation is based on @awson's patches to binutils.
      
      Binutils requires some extra help when compiling the libraries
      for GHCi usage. We drop the `-T` and use implicit scripts to amend
      the linker scripts instead of replacing it.
      
      Because of these very large GHCi object files, we need big-obj support,
      which will be added by another patch.
      
      Test Plan: ./validate
      
      Reviewers: awson, austin, bgamari
      
      Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force
      
      GHC Trac Issues: #12913
      
      Differential Revision: https://phabricator.haskell.org/D3383
      bd4fdc6a
  23. 29 Jun, 2017 2 commits
    • erdeszt's avatar
      Allow optional instance keyword in associated type family instances · 007f2556
      erdeszt authored
      Add the missing branch for parsing the optional 'instance' keyword
      in associated type family instance declarations.
      
      Fixes #13747
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, RyanGlScott, rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3673
      007f2556
    • Simon Peyton Jones's avatar
      Revert "Remove the Windows GCC driver." · 58c781da
      Simon Peyton Jones authored
      This reverts commit d6cecde5.
      
      The patch broke Simon PJ's Windows build, becuase he didn't
      have (and should not need) a separate msys2 gcc.
      
      Following an exchange on the ghc-devs list, Tamar wrote
      
        Oops, sorry, didn’t notice it because both mine and harbormaster’s
        msys2 have separate GCCs installed as well.
      
        I don’t see an easy fix that would also work for end user Configure
        based cabal installs. So I think I’ll have to go back to the drawing
        board for this one.
      
        You can just leave it reverted.
      58c781da
  24. 17 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Remove the Windows GCC driver. · d6cecde5
      Tamar Christina authored
      Summary:
      This patch drops the GCC driver and instead moves
      the only remaining path that we need to keep for
      backwards compatibility to the settings file.
      
      It also generalizes the code that expands `$TopDir`
      so it can expand it within any location in the string
      and also changes it so `$TopDir` is expanded only
      after the words call because `$TopDir` can contains
      spaces which would be horribly broken.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      GHC Trac Issues: #13709
      
      Differential Revision: https://phabricator.haskell.org/D3592
      d6cecde5
  25. 16 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Provide way to build using existing C compiler on Windows. · fda094d0
      Tamar Christina authored
      Summary:
      There are various distros that build GHC using their own C compilers
      such as MSYS2. Currently they have to patch the build scripts everytime.
      
      This patch provides the configure argument `--enable-distro-toolchain`
      which allows one to build using any C compiler on the path.
      
      This is also useful for testing new versions of GCC.
      
      Test Plan:
      ./configure --enable-distro-toolchain && make - && make THREADS=9 test
      ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #13792
      
      Differential Revision: https://phabricator.haskell.org/D3637
      fda094d0
  26. 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 ...
      8e6ec0fa
  27. 02 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Better import library support for Windows · 93489cd3
      Tamar Christina authored
      The import library support added for 7.10.3 was only a partial one.
      This support was predicated on using file extensions to determine
      whether or not a library was an import library. It also couldn't handle
      libraries with multiple dll pointers.
      
      This is a rewrite of that patch and fully integrating it into the normal
      archive parsing and loading routines. This solves a host of issues,
      among others allowing us to finally use `-lgcc_s`.
      
      This also fixes a problem with our previous implementation, where we
      just loaded the DLL and moved on. Doing this had the potential of using
      the wrong symbol at resolve time. Say a DLL already loaded (A.dll) has
      symbol a exported (dependency of another dll perhaps).
      
      We find an import library `B.lib` explicitly defining an export of `a`.
      we load `B.dll` but this gets put after `A.dll`, at resolve time we
      would use the value from `A` instead of `B` which is what we wanted.
      
      Test Plan: ./valide and make test TEST=13606
      
      Reviewers: austin, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force
      
      GHC Trac Issues: #13606, #12499, #12498
      
      Differential Revision: https://phabricator.haskell.org/D3513
      93489cd3
  28. 08 May, 2017 1 commit
  29. 25 Apr, 2017 1 commit
  30. 17 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      hs_add_root() RTS API removal · a92ff5d6
      Sergei Trofimovich authored
      Before ghc-7.2 hs_add_root() had to be used to initialize haskell
      modules when haskell was called from FFI.
      
      commit a52ff761
      
      
      ("Change the way module initialisation is done (#3252, #4417)")
      removed needs for hs_add_root() and made function a no-op.
      For backward compatibility '__stginit_<module>' symbol was
      not removed.
      
      This change removes no-op hs_add_root() function and unused
      '__stginit_<module>' symbol from each haskell module.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3460
      a92ff5d6