1. 22 Nov, 2018 4 commits
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
         Fix unused-import stuff in a better way
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      This led to Trac #13064 and #15393
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      The two important changes are
      * Fix the bug in bestImport
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      In unravalling this I also ended up doing a few other things
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      * Delete dead code RdrName.greUsedRdrName
      Bumps a few submodules.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5312
    • Krzysztof Gogolewski's avatar
      Don't pass -no-pie when -pgmc is supplied · 8d008b71
      Krzysztof Gogolewski authored
      Test Plan: validate
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15319
      Differential Revision: https://phabricator.haskell.org/D5317
    • Roland Senn's avatar
      Calling gcc: Pass optc flags as last options (#14452) · f2d9fb0c
      Roland Senn authored
      Test Plan: make test TEST=T14452
      Reviewers: hvr, bgamari, monoidal, thomie, osa1
      Reviewed By: osa1
      Subscribers: rwbarton, carter
      GHC Trac Issues: #14452
      Differential Revision: https://phabricator.haskell.org/D5318
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      Subscribers: tdammers, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4881
  2. 19 Nov, 2018 1 commit
    • Sebastian Graf's avatar
      Don't track free variables in STG syntax by default · 47bbc709
      Sebastian Graf authored
      Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global
      free variables.  This free variable information is only needed in the final
      code generation step (i.e. `StgCmm.codeGen`), which leads to transformations
      such as `StgCse` and `StgUnarise` having to maintain this information.
      This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like
      approach that only introduces the free variable set into the syntax tree in the
      code gen pass, along with a free variable analysis on STG terms to generate
      that information.
      Fixes #15754.
      Reviewers: simonpj, osa1, bgamari, simonmar
      Reviewed By: osa1
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15754
      Differential Revision: https://phabricator.haskell.org/D5324
  3. 17 Nov, 2018 2 commits
    • Krzysztof Gogolewski's avatar
      Building GHC with hadrian on FreeBSD · 65517979
      Krzysztof Gogolewski authored
      Summary: I'm currently trying to make `hadrian` work as a build system
      on FreeBSD (https://ghc.haskell.org/trac/ghc/ticket/15860).
      I'm still having some issues with `libgmp` but one can get a working
      `ghc` using `--integer-simple` and this patch.
      Reviewers: bgamari, erikd, alpmestan
      Reviewed By: alpmestan
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5335
    • Andreas Klebinger's avatar
      NCG: New code layout algorithm. · 912fd2b6
      Andreas Klebinger authored
      This patch implements a new code layout algorithm.
      It has been tested for x86 and is disabled on other platforms.
      Performance varies slightly be CPU/Machine but in general seems to be better
      by around 2%.
      Nofib shows only small differences of about +/- ~0.5% overall depending on
      flags/machine performance in other benchmarks improved significantly.
      Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec,
      containers, text and xeno.
      While the magnitude of gains differed three different CPUs where tested with
      all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell,
      * Library benchmark results summarized:
        * containers: ~1.5% faster
        * aeson: ~2% faster
        * megaparsec: ~2-5% faster
        * xml library benchmarks: 0.2%-1.1% faster
        * vector-benchmarks: 1-4% faster
        * text: 5.5% faster
      On average GHC compile times go down, as GHC compiled with the new layout
      is faster than the overhead introduced by using the new layout algorithm,
      Things this patch does:
      * Move code responsilbe for block layout in it's own module.
      * Move the NcgImpl Class into the NCGMonad module.
      * Extract a control flow graph from the input cmm.
      * Update this cfg to keep it in sync with changes during
        asm codegen. This has been tested on x64 but should work on x86.
        Other platforms still use the old codelayout.
      * Assign weights to the edges in the CFG based on type and limited static
        analysis which are then used for block layout.
      * Once we have the final code layout eliminate some redundant jumps.
        In particular turn a sequences of:
            jne .foo
            jmp .bar
            je bar
      Test Plan: ci
      Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton
      GHC Trac Issues: #15124
      Differential Revision: https://phabricator.haskell.org/D4726
  4. 12 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      compareByPreference: handle the integer-gmp vs -simple case · 86ee74dc
      Alp Mestanogullari authored
      Currently, it assumes the package names are identical and this
      breaks in the case where integer-gmp is in one package db and
      integer-simple in another. This became a problem with
      the commit: fc2ff6dd.
      Instead of following the precedence information, leading to
      the right choice, the current code would compare the
      integer-gmp and integer-simple versions and pick integer-gmp
      because it happened to have a greater version, despite having
      a lower precedence. See
      https://github.com/snowleopard/hadrian/issues/702 for
      a comprehensive report about the problem.
      This effectively un-breaks integer-simple builds with hadrian.
      Test Plan: hadrian/build.sh --integer-simple
      Reviewers: snowleopard, bgamari
      Reviewed By: bgamari
      Subscribers: snowleopard, rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5266
  5. 29 Oct, 2018 2 commits
    • Richard Eisenberg's avatar
      Revert "Remove kind generalisation from tcRnType" · 09740d50
      Richard Eisenberg authored
      This reverts commit 3a51abd0.
      I had hit the wrong button when trying to validate the original
      commit... and ended up committing it prematurely instead.
      This reversion commit
      also updates the comments to explain why we kind-generalise.
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      As a bonus, we now have more control over the ordering of such
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      Test cases: dependent/should_fail/T14880{,-2},
  6. 28 Oct, 2018 1 commit
  7. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      This modifies the Template Haskell AST -- old code may break!
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      Includes submodule update for Haddock.
      Test Plan: validate
      Reviewers: goldfire, bgamari, alanz
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      GHC Trac Issues: #2600, #14268
      Differential Revision: https://phabricator.haskell.org/D4894
  8. 15 Oct, 2018 2 commits
  9. 14 Oct, 2018 1 commit
  10. 12 Oct, 2018 1 commit
  11. 11 Oct, 2018 1 commit
    • Piyush P Kurur's avatar
      Support builtin classes like KnownNat in backpack · ce7a1c4a
      Piyush P Kurur authored
      This commit allows backpack signatures to enforce constraints like
      on data types.  Thus it fixes #15379.  There were two important
      differences in the
      way GHC used to handle classes like KnowNat
      1.  Hand crafted instances of `KnownNat` were  forbidden, and
      2. The dictionary for an  instance `KnownNat T` was generated on the
      For supporting backpack both these points have to be revisited.
      Disallowing instances of KnownNat
      Users were disallowed to declare instances of certain builtin classes
      like KnownNat for obvious safety reasons --- when we use the
      constraint like `KnownNat T`, we want T to be associated to a natural
      number. However, due to the reuse of this code while processing backpack
      signatures, `instance KnownNat T` were being disallowed even in module
      signature files.
      There is an important difference when it comes to instance declarations
      in a signature file. Consider the signature `Abstract` given below
      signature Abstract where
        data T :: Nat
        instance KnownNat T
      Inside a signature like `Abstract`, the `instance Known T` is not really
      creating an instance but rather demanding any module that implements
      this signature to enforce the constraint `KnownNat` on its type
      T.  While hand crafted KnownNat instances continued to be prohibited in
      this commit ensures that it is not forbidden while handling signatures.
      Resolving Dictionaries
      Normally GHC expects any instance `T` of class `KnownNat` to eventually
      to an integer and hence used to generate the evidence/dictionary for
      such instances
      on the fly as in when it is required. However, when backpack module and
      signatures are involved
      It is not always possible to resolve the type to a concrete integer
      utill the mixin stage. To illustrate
      consider again the  signature `Abstract`
      > signature Abstract where
      >   data T :: Nat
      >   instance KnownNat T
      and a module `Util` that depends on it:
      > module Util where
      >     import Abstract
      >     printT :: IO ()
      >     printT = do print $ natVal (Proxy :: Proxy T)
      Clearly, we need to "use" the dictionary associated with `KnownNat T`
      in the module `Util`, but it is too early for the compiler to produce
      a real dictionary as we still have not fixed what `T` is. Only when we
      mixin a concrete module
      > module Concrete where
      >   type T = 42
      do we really get hold of the underlying integer.
      In this commit, we make the following changes in the resolution of
      instance dictionary
      for constraints like `KnownNat T`
      1. If T is indeed available as a type alias for an integer constant,
         generate the dictionary on the fly as before, failing which
      2. Do not give up as before but look up the type class environment for
      the evidence.
      This was enough to make the resolution of `KnownNat` dictionaries work
      in the setting of Backpack as
      when actual code is generated, the signature Abstract (due to the
      `import Abstract` ) in `Util` gets
      replaced by an actual module like Concrete, and resolution happens as
      Everything that we said for `KnownNat` is applicable for `KnownSymbol`
      as well.
      Reviewers: bgamari, ezyang, goldfire, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, ezyang, rwbarton, thomie, carter
      GHC Trac Issues: #15379
      Differential Revision: https://phabricator.haskell.org/D4988
  12. 03 Oct, 2018 2 commits
    • Joachim Breitner's avatar
      Make GHC (the library) flexible in the choice of integer library · fc2ff6dd
      Joachim Breitner authored
      We have more and more users of GHC as a library, for example the
      Haskell-to-WebAssembly-compiler https://github.com/tweag/asterius.
      These need to make different decisions about various aspects of
      code generation than the host compiler, and ideally GHC-the-library
      allows them to set the `DynFlags` as needed.
      This patch adds a new `DynFlag` that configures which `integer`
      library to use. This flag is initialized by `cIntegerLibraryType`
      (as before), and is only used in `CorePrep` to decide whether to
      use `S#` or not.
      The other code paths that were varying based on `cIntegerLibraryType`
      are no now longer varying: The trick is to use `integer-wired-in`
      as the `-this-unit-id` when compiling either `integer-gmp` or
      Test Plan: Validate is happy.
      Reviewers: hvr, bgamari
      Reviewed By: bgamari
      Subscribers: TerrorJack, adamse, simonpj, rwbarton, carter
      GHC Trac Issues: #13477
      Differential Revision: https://phabricator.haskell.org/D5079
    • Ryan Scott's avatar
      Drop GHC 8.2 compatibility · a838ae37
      Ryan Scott authored
      GHC 8.6.1 is out, so now GHC's support window only extends
      back to GHC 8.4. This means we can delete gobs of code that were
      only used for GHC 8.2 support. Hooray!
      Test Plan: ./validate
      Reviewers: bgamari, Phyx, erikd
      Reviewed By: bgamari, Phyx
      Subscribers: rwbarton, erikd, carter
      Differential Revision: https://phabricator.haskell.org/D5192
  13. 02 Oct, 2018 1 commit
  14. 28 Sep, 2018 2 commits
  15. 16 Sep, 2018 1 commit
  16. 12 Sep, 2018 1 commit
  17. 11 Sep, 2018 1 commit
  18. 07 Sep, 2018 1 commit
  19. 05 Sep, 2018 1 commit
  20. 04 Sep, 2018 1 commit
  21. 30 Aug, 2018 1 commit
  22. 28 Aug, 2018 1 commit
  23. 25 Aug, 2018 1 commit
    • Tamar Christina's avatar
      ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0 · c523525b
      Tamar Christina authored
      This completes the work started in D4227 by using just 'getExecutablePath'
      in ghc and ghc-pkg when building with base >= 4.11.0.
      On the long term, we will be able to simply kill the existing code that
      follows (or not) symlinks and just get this behaviour for free from
      getExecutable. For now we however have to require base >= 4.11.0 to be able
      to just use getExecutablePath under Windows, and use the current code when
      building with an older base.
      Original code by @alpmestan commandeering since patch has been stale
      and bug remains open.
      Test Plan: Validate
      Reviewers: angerman, bgamari, erikd, alpmestan
      Reviewed By: bgamari
      Subscribers: carter, rwbarton, thomie
      GHC Trac Issues: #14483
      Differential Revision: https://phabricator.haskell.org/D4229
  24. 24 Aug, 2018 1 commit
  25. 22 Aug, 2018 1 commit
  26. 21 Aug, 2018 4 commits
    • Alec Theriault's avatar
      Explicitly tell 'getNameToInstances' mods to load · c971e119
      Alec Theriault authored
      Calculating which modules to load based on the InteractiveContext means
      maintaining a potentially very large GblRdrEnv.
      In Haddock's case, it is much cheaper (from a memory perspective) to
      just keep track of which modules interfaces we want loaded then hand
      these off explicitly to 'getNameToInstancesIndex'.
      Bumps haddock submodule.
      Reviewers: alexbiehl, bgamari
      Reviewed By: alexbiehl
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D5003
    • Roland Senn's avatar
      Introduce flag -keep-hscpp-files · ebcbfba7
      Roland Senn authored
      Test Plan: `make test=T10869`
      Reviewers: mpickering, thomie, ezyang, bgamari
      Reviewed By: thomie, bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #10869
      Differential Revision: https://phabricator.haskell.org/D4861
    • Andreas Klebinger's avatar
      Replace most occurences of foldl with foldl'. · 09c1d5af
      Andreas Klebinger authored
      This patch adds foldl' to GhcPrelude and changes must occurences
      of foldl to foldl'. This leads to better performance especially
      for quick builds where GHC does not perform strictness analysis.
      It does change strictness behaviour when we use foldl' to turn
      a argument list into function applications. But this is only a
      drawback if code looks ONLY at the last argument but not at the first.
      And as the benchmarks show leads to fewer allocations in practice
      at O2.
      Compiler performance for Nofib:
      O2 Allocations:
              -1 s.d.                -----            -0.0%
              +1 s.d.                -----            -0.0%
              Average                -----            -0.0%
      O2 Compile Time:
              -1 s.d.                -----            -2.8%
              +1 s.d.                -----            +1.3%
              Average                -----            -0.8%
      O0 Allocations:
              -1 s.d.                -----            -0.2%
              +1 s.d.                -----            -0.1%
              Average                -----            -0.2%
      Test Plan: ci
      Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal
      Reviewed By: bgamari, monoidal
      Subscribers: tdammers, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4929
    • Sergei Trofimovich's avatar
      driver: unconditionally disable relaxation when linking partially · 1cc9061f
      Sergei Trofimovich authored
      In https://github.com/gentoo-haskell/gentoo-haskell/issues/704
      user explicitly uses -Wl,--relax for most built binaries.
      Most of the time this works fine except for capi haskell code
      similar to the following:
      {-# LANGUAGE CApiFFI #-}
      module Z where
      import Foreign.C
      foreign import capi "unistd.h close" c_close :: CInt -> IO CInt
      In this case compilation fails as:
      $ inplace/bin/ghc-stage2 -c Z.hs -optl-Wl,--relax -fforce-recomp
      ld: --relax and -r may not be used together
      GHC's driver already disables relaxation on sparc as there relaxation
      is already a default mode.
      This change disables relaxation on partial linking for all platforms
      where linker is binutils linker.
      Reported-by: wmyrda
      Bug: https://github.com/gentoo-haskell/gentoo-haskell/issues/704Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      Test Plan: pass -optl-Wl,--relax in test above
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4888
  27. 07 Aug, 2018 1 commit
    • Herbert Valerio Riedel's avatar
      Turn on MonadFail desugaring by default · aab8656b
      Herbert Valerio Riedel authored
      This contains two commits:
      Make GHC's code-base compatible w/ `MonadFail`
      There were a couple of use-sites which implicitly used pattern-matches
      in `do`-notation even though the underlying `Monad` didn't explicitly
      support `fail`
      This refactoring turns those use-sites into explicit case
      discrimations and adds an `MonadFail` instance for `UniqSM`
      (`UniqSM` was the worst offender so this has been postponed for a
      follow-up refactoring)
      Turn on MonadFail desugaring by default
      This finally implements the phase scheduled for GHC 8.6 according to
      This also preserves some tests that assumed MonadFail desugaring to be
      active; all ghc boot libs were already made compatible with this
      `MonadFail` long ago, so no changes were needed there.
      Test Plan: Locally performed ./validate --fast
      Reviewers: bgamari, simonmar, jrtc27, RyanGlScott
      Reviewed By: bgamari
      Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D5028
  28. 06 Aug, 2018 1 commit
  29. 01 Aug, 2018 1 commit
    • Christiaan Baaij's avatar
      Plugin dependency information is stored separately · 52065e95
      Christiaan Baaij authored
      We need to store the used plugins so that we recompile
      a module when a plugin that it uses is recompiled.
      However, storing the `ModuleName`s of the plugins used by a
      module in the `dep_mods` field made the rest of GHC think
      that they belong in the HPT, causing at least the issues
      reported in #15234
      We therefor store the `ModuleName`s of the plugins in a
      new field, `dep_plgins`, which is only used the the
      recompilation logic.
      Reviewers: mpickering, bgamari
      Reviewed By: mpickering, bgamari
      Subscribers: alpmestan, rwbarton, thomie, carter
      GHC Trac Issues: #15234
      Differential Revision: https://phabricator.haskell.org/D4937