1. 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
  2. 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
  3. 31 Jul, 2017 1 commit
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
  11. 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
  12. 08 May, 2017 1 commit
  13. 25 Apr, 2017 1 commit
    • Ben Gamari's avatar
      configure: Kill off FP_ARG_WITH_* · 9373994a
      Ben Gamari authored
      This replaces the --with-* configure flags with the usual autoconf
      environment variables, as suggested by #13583.
      
      Test Plan: Configure on various platforms
      
      Reviewers: hvr, trofi, thomie, austin
      
      Reviewed By: trofi
      
      Subscribers: rwbarton, erikd
      
      GHC Trac Issues: #13583
      
      Differential Revision: https://phabricator.haskell.org/D3499
      9373994a
  14. 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
  15. 02 Apr, 2017 1 commit
    • David Feuer's avatar
      Derive the definition of null · bf5e0eab
      David Feuer authored
      We can sometimes produce much better code by deriving the
      definition of `null` rather than using the default. For example,
      given
      
          data SnocList a = Lin | Snoc (SnocList a) a
      
      the default definition of `null` will walk the whole list, but of
      course we can stop as soon as we see `Snoc`. Similarly, if a
      constructor contains some other `Foldable` type, we want to use its
      `null` rather than folding over the structure.
      
      Partially fixes Trac #13280
      
      Reviewers: austin, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3402
      bf5e0eab
  16. 30 Mar, 2017 1 commit
    • David Feuer's avatar
      Deriving for phantom and empty types · 69f070d8
      David Feuer authored
      Make `Functor`, `Foldable`, and `Traversable` take advantage
      of the case where the type parameter is phantom. In this case,
      
      * `fmap _ = coerce`
      * `foldMap _ _ = mempty`
      * `traverse _ x = pure (coerce x)`
      
      For the sake of consistency and especially simplicity, make other types
      with no data constructors behave the same:
      
      * `fmap _ x = case x of`
      * `foldMap _ _ = mempty`
      * `traverse _ x = pure (case x of)`
      
      Similarly, for `Generic`,
      
      * `to x = case x of`
      * `from x = case x of`
      
      Give all derived methods for types without constructors appropriate
      arities. For example,
      
      ```
          compare _ _ = error ...
      ```
      
      rather than
      
      ```
          compare = error ...
      ```
      
      Fixes #13117 and #13328
      
      Reviewers: austin, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: ekmett, RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3374
      69f070d8