1. 22 Nov, 2018 2 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
      6353efc7
    • 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
      8d008b71
  2. 19 Nov, 2018 1 commit
    • Sebastian Graf's avatar
      Don't track free variables in STG syntax by default · 47bbc709
      Sebastian Graf authored
      Summary:
      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
      47bbc709
  3. 17 Nov, 2018 1 commit
    • Andreas Klebinger's avatar
      NCG: New code layout algorithm. · 912fd2b6
      Andreas Klebinger authored
      Summary:
      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,
      Skylake
      
      * 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
          foo:
        into
            je bar
          foo:
            ..
      
      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
      912fd2b6
  4. 15 Oct, 2018 2 commits
  5. 12 Oct, 2018 1 commit
  6. 03 Oct, 2018 1 commit
    • Joachim Breitner's avatar
      Make GHC (the library) flexible in the choice of integer library · fc2ff6dd
      Joachim Breitner authored
      Summary:
      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
      `integer-simple`.
      
      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
      fc2ff6dd
  7. 28 Sep, 2018 2 commits
  8. 28 Aug, 2018 1 commit
  9. 21 Aug, 2018 2 commits
    • 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
      ebcbfba7
    • 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
      09c1d5af
  10. 07 Aug, 2018 1 commit
    • Herbert Valerio Riedel's avatar
      Turn on MonadFail desugaring by default · aab8656b
      Herbert Valerio Riedel authored
      Summary:
      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
      
      https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy
      
      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
      aab8656b
  11. 16 Jul, 2018 1 commit
    • Vladislav Zavialov's avatar
      Do not imply NoStarIsType by TypeOperators/TypeInType · 65c186f0
      Vladislav Zavialov authored
      Implementation of the "Embrace TypeInType" proposal was done according
      to the spec, which specified that TypeOperators must imply NoStarIsType.
      This implication was meant to prevent breakage and to be removed in 2
      releases.  However, compiling head.hackage has shown that this
      implication only magnified the breakage, so there is no reason to have
      it in the first place.
      
      To remain in compliance with the three-release policy, we add a
      workaround to define the (*) type operator even when -XStarIsType is on.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: harpocrates, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4865
      65c186f0
  12. 12 Jul, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Add flag to show docs of valid hole fits · c4d98341
      Matthías Páll Gissurarson authored
      One issue with valid hole fits is that the function names can often be
      opaque for the uninitiated, such as `($)`. This diff adds a new flag,
      `-fshow-docs-of-hole-fits` that adds the documentation of the identifier
      in question to the message, using the same mechanism as the `:doc`
      command.
      
      As an example, with this flag enabled, the valid hole fits for `_ ::
      [Int] -> Int` will include:
      
      ```
      Valid hole fits include
        head :: forall a. [a] -> a
          {-^ Extract the first element of a list, which must be non-empty.-}
          with head @Int
          (imported from ‘Prelude’ (and originally defined in ‘GHC.List’))
      ```
      
      And one of the refinement hole fits, `($) _`, will read:
      
      ```
      Valid refinement hole fits include
        ...
        ($) (_ :: [Int] -> Int)
            where ($) :: forall a b. (a -> b) -> a -> b
            {-^ Application operator.  This operator is redundant, since ordinary
                application @(f x)@ means the same as @(f '$' x)@. However, '$' has
                low, right-associative binding precedence, so it sometimes allows
                parentheses to be omitted; for example:
      
                > f $ g $ h x  =  f (g (h x))
      
                It is also useful in higher-order situations, such as @'map' ('$' 0) xs@,
                or @'Data.List.zipWith' ('$') fs xs@.
      
                Note that @($)@ is levity-polymorphic in its result type, so that
                    foo $ True    where  foo :: Bool -> Int#
                is well-typed-}
            with ($) @'GHC.Types.LiftedRep @[Int] @Int
            (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
      
      ```
      
      Another example of where documentation can come in very handy, is when
      working with the `lens` library.
      
      When you compile
      ```
      {-# OPTIONS_GHC -fno-show-provenance-of-hole-fits -fshow-docs-of-hole-fits #-}
      module LensDemo where
      
      import Control.Lens
      import Control.Monad.State
      
      newtype Test = Test { _value :: Int } deriving (Show)
      
      value :: Lens' Test Int
      value f (Test i) = Test <$> f i
      
      updTest :: Test -> Test
      updTest t = t &~ do
          _ value (1 :: Int)
      ```
      
      You get:
      ```
        Valid hole fits include
          (#=) :: forall s (m :: * -> *) a b.
                  MonadState s m =>
                  ALens s s a b -> b -> m ()
            {-^ A version of ('Control.Lens.Setter..=') that works on 'ALens'.-}
            with (#=) @Test @(StateT Test Identity) @Int @Int
          (<#=) :: forall s (m :: * -> *) a b.
                   MonadState s m =>
                   ALens s s a b -> b -> m b
            {-^ A version of ('Control.Lens.Setter.<.=') that works on 'ALens'.-}
            with (<#=) @Test @(StateT Test Identity) @Int @Int
          (<*=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Multiply the target of a numerically valued 'Lens' into your 'Monad''s
                state and return the result.
      
                When you do not need the result of the multiplication,
                ('Control.Lens.Setter.*=') is more flexible.
      
                @
                ('<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<*=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
                @-}
            with (<*=) @Test @(StateT Test Identity) @Int
          (<+=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Add to the target of a numerically valued 'Lens' into your 'Monad''s state
                and return the result.
      
                When you do not need the result of the addition,
                ('Control.Lens.Setter.+=') is more flexible.
      
                @
                ('<+=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<+=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
                @-}
            with (<+=) @Test @(StateT Test Identity) @Int
          (<-=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Subtract from the target of a numerically valued 'Lens' into your 'Monad''s
                state and return the result.
      
                When you do not need the result of the subtraction,
                ('Control.Lens.Setter.-=') is more flexible.
      
                @
                ('<-=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<-=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
                @-}
            with (<-=) @Test @(StateT Test Identity) @Int
          (<<*=) :: forall s (m :: * -> *) a.
                    (MonadState s m, Num a) =>
                    LensLike' ((,) a) s a -> a -> m a
            {-^ Modify the target of a 'Lens' into your 'Monad''s state by multipling a value
                and return the /old/ value that was replaced.
      
                When you do not need the result of the operation,
                ('Control.Lens.Setter.*=') is more flexible.
      
                @
                ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Iso'' s a -> a -> m a
                @-}
            with (<<*=) @Test @(StateT Test Identity) @Int
          (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)
      
      ```
      
      Which allows you to see at a glance what opaque operators like `(<<*=)`
      and `(<#=)` do.
      
      Reviewers: bgamari, sjakobi
      
      Reviewed By: sjakobi
      
      Subscribers: sjakobi, alexbiehl, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4848
      c4d98341
  13. 06 Jul, 2018 1 commit
  14. 22 Jun, 2018 1 commit
  15. 20 Jun, 2018 1 commit
    • Moritz Angermann's avatar
      Fix gcc.exe: error: CreateProcess: No such file or directory · 227ede4a
      Moritz Angermann authored
      When GHC links binaries on windows, we pass a -L and -l flag
      to gcc for each dependency in the transitive dependency
      closure.  As this will usually overflow the command argument
      limit on windows, we use response files to pass all arguments
      to gcc.  gcc however internally passes only the -l flags via
      a response file to the collect2 command, but puts the -L flags
      on the command line. As such if we pass enough -L flags to
      gcc--even via a response file--we will eventually overflow the
      command line argument length limit due to gcc passing them
      to collect2 without resorting to a response file.
      
      To prevent this from happening we move all lirbaries into a
      shared temporary folder, and only need to pass a single -L
      flag to gcc.  Ideally however this was fixed in gcc.
      
      Reviewers: bgamari, Phyx
      
      Reviewed By: bgamari
      
      Subscribers: erikd, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4762
      227ede4a
  16. 18 Jun, 2018 1 commit
  17. 17 Jun, 2018 3 commits
    • Vladislav Zavialov's avatar
      Add -Werror=compat · 04e9fe5c
      Vladislav Zavialov authored
      Add a flag `-Werror=compat` to GHC which has the effect of `-Werror=x
      -Werror=y ...`, where `x, y, ...` are warnings from the `-Wcompat`
      option group.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15278
      
      Differential Revision: https://phabricator.haskell.org/D4860
      04e9fe5c
    • Vladislav Zavialov's avatar
      Warn about implicit kind variables with -Wcompat · 8df24474
      Vladislav Zavialov authored
      According to an accepted proposal
      https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002
      4-no-kind-vars.rst
      
          With -Wcompat, warn if a kind variable is brought into scope
          implicitly in a type with an explicit forall. This applies to type
          signatures and to other contexts that allow a forall with the
          forall-or-nothing rule in effect (for example, class instances).
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, RyanGlScott
      
      Reviewed By: goldfire
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #15264
      
      Differential Revision: https://phabricator.haskell.org/D4834
      8df24474
    • Sylvain Henry's avatar
      Enhanced constant folding · 60e4bb4d
      Sylvain Henry authored
      Until now GHC only supported basic constant folding (lit op lit, expr op
      0, etc.).
      
      This patch uses laws of +/-/* (associativity, commutativity,
      distributivity) to support some constant folding into nested
      expressions.
      
      Examples of new transformations:
      
         - simple nesting: (10 + x) + 10 becomes 20 + x
         - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t)))
         - distribution: (5 + x) * 6 becomes 30 + 6*x
         - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x)
         - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      GHC Trac Issues: #9136
      
      Differential Revision: https://phabricator.haskell.org/D2858
      
      (cherry picked from commit fea04def)
      60e4bb4d
  18. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15195
      
      Differential Revision: https://phabricator.haskell.org/D4748
      d650729f
  19. 05 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Introduce DerivingVia · 8ed8b037
      Ryan Scott authored
      This implements the `DerivingVia` proposal put forth in
      https://github.com/ghc-proposals/ghc-proposals/pull/120.
      
      This introduces the `DerivingVia` deriving strategy. This is a
      generalization of `GeneralizedNewtypeDeriving` that permits the user
      to specify the type to `coerce` from.
      
      The major change in this patch is the introduction of the
      `ViaStrategy` constructor to `DerivStrategy`, which takes a type
      as a field. As a result, `DerivStrategy` is no longer a simple
      enumeration type, but rather something that must be renamed and
      typechecked. The process by which this is done is explained more
      thoroughly in section 3 of this paper
      ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ),
      although I have inlined the relevant parts into Notes where possible.
      
      There are some knock-on changes as well. I took the opportunity to
      do some refactoring of code in `TcDeriv`, especially the
      `mkNewTypeEqn` function, since it was bundling all of the logic for
      (1) deriving instances for newtypes and
      (2) `GeneralizedNewtypeDeriving`
      into one huge broth. `DerivingVia` reuses much of part (2), so that
      was factored out as much as possible.
      
      Bumps the Haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, goldfire, alanz
      
      Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15178
      
      Differential Revision: https://phabricator.haskell.org/D4684
      8ed8b037
  20. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      
      The main ticket is Trac #2893, but also relevant are
        #5927
        #8516
        #9123 (especially!  higher kinded roles)
        #14070
        #14317
      
      The wiki page is
        https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      
      Here is the relevant Note:
      
      Note [Quantified constraints]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The -XQuantifiedConstraints extension allows type-class contexts like
      this:
      
        data Rose f x = Rose x (f (Rose f x))
      
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
      
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
      
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
      
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
      
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
      
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
      
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
      
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
      
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
      
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      
      Some other related refactoring
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
        unifiers
      7df58960
  21. 03 Jun, 2018 2 commits
    • Andreas Klebinger's avatar
      Allow aligning of cmm procs at specific boundry · f68c2cb6
      Andreas Klebinger authored
      Allows to align CmmProcs at the given boundries.
      
      It makes performance usually worse but can be helpful
      to limit the effect of a unrelated function B becoming
      faster/slower after changing function A.
      
      Test Plan: ci, using it.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15148
      
      Differential Revision: https://phabricator.haskell.org/D4706
      f68c2cb6
    • Tobias Dammers's avatar
      Turn "inaccessible code" error into a warning · 08073e16
      Tobias Dammers authored
      With GADTs, it is possible to write programs such that the type
      constraints make some code branches inaccessible.
      
      Take, for example, the following program ::
      
          {-# LANGUAGE GADTs #-}
      
          data Foo a where
           Foo1 :: Foo Char
           Foo2 :: Foo Int
      
          data TyEquality a b where
                  Refl :: TyEquality a a
      
          checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u)
          checkTEQ x y = error "unimportant"
      
          step2 :: Bool
          step2 = case checkTEQ Foo1 Foo2 of
                   Just Refl -> True -- Inaccessible code
                   Nothing -> False
      
      Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1`
      and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl`
      constructor essentially mandates `t ~ u`, and thus `Char ~ Int`.
      
      Previously, GHC would reject such programs entirely; however, in
      practice this is too harsh. Accepting such code does little harm, since
      attempting to use the "impossible" code will still produce errors down
      the chain, while rejecting it means we cannot legally write or generate
      such code at all.
      
      Hence, we turn the error into a warning, and provide
      `-Winaccessible-code` to control GHC's behavior upon encountering this
      situation.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11066
      
      Differential Revision: https://phabricator.haskell.org/D4744
      08073e16
  22. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  23. 30 May, 2018 2 commits
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
    • Kavon Farvardin's avatar
      Extract hard-coded LLVM opt flags into a file · a4ae199c
      Kavon Farvardin authored
      To resolve ticket #11295, I think it makes sense to stop hard-coding
      the pass sequences used by GHC when compiling with LLVM into the
      compiler
      itself.
      
      This patchset introduces a companion to the existing `llvm-targets` file
      called `llvm-passes`. The passes file is a simple association list that
      holds the default LLVM `opt` pass sequence used by GHC. This allows end
      users to easily save their favorite optimization flags when compiling
      with LLVM.
      
      The main benefit for ticket #11295 is that when adding a custom pass
      sequence, it tends to be an extremely long string that would be
      unsightly in the code.
      
      This is essentially part 1 of 2 for ticket #11295.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, angerman
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4695
      a4ae199c
  24. 25 May, 2018 1 commit
    • Simon Marlow's avatar
      Add -fghci-leak-check to check for space leaks · 5b6ef59f
      Simon Marlow authored
      Summary:
      (re-applying this patch now that D4659 is committed)
      
      Space leaks in GHCi emerge from time to time and tend to come back again
      after they get fixed. This is an attempt to limit regressions by
      
      * adding a reliable detection for some classes of space leaks in GHCi
      * turning on leak checking for all GHCi tests in the test suite, so that
        we'll notice if the leak appears again.
      
      The idea for detecting space leaks is quite simple:
      
      * find some data that we expect to be GC'd later, make a weak pointer to it
      * when we expect the data to be dead, do a `performGC` and then check
        the status of the weak pointer.
      
      It would be nice to apply this trick to lots of things in GHC,
      e.g. ensuring that HsSyn is not retained after the desugarer, or
      ensuring that CoreSyn from the previous simplifier pass is not retained.
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, erikd, niteria
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15111
      5b6ef59f
  25. 15 May, 2018 1 commit
    • Artem Pelenitsyn's avatar
      Less Tc inside simplCore (Phase 1 for #14391) · bb3fa2d1
      Artem Pelenitsyn authored
      Simplifier depends on typechecker in two points: `thNameToGhcName`
      (`lookupThName_maybe`, in particular)  and `lookupGlobal`. We want to
      cut the ties in two steps.
      
      1. (Presented in this commit), reimplement both functions in a way that
      doesn't use typechecker.
      
      2. (Should follow), do code moving: a) `lookupGlobal` should go in some
      typechecker-free place; b) `thNameToGhcName` should leave simplifier,
      because it is not used there at all (probably, it should be placed
      somewhere where `GhcPlugins` can see it -- this is suggested by Joachim
      on Trac).
      
      Details
      =======
      
      We redesigned lookup interface a bit so that it exposes some
      `IO`-equivalents of `Tc`-features in use.
      
      First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer
      bound to the typechecker monad, but still resides in `TcEnv.hs` — it
      should be moved out of Tc-land at some point (“Phase 2”) in the
      future in order to achieve its part of the #14391's goal.
      
      Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs`
      completely; this already achieves its part of the goal of #14391. Its
      client, though, `thNameToGhcName`, is better to be moved in the future
      also, for it is not used in the `CoreMonad.hs` (or anywhere else)
      anyway. Joachim suggested “any module reexported by GhcPlugins (or
      maybe even that module itself)”.
      
      As a side goal, we removed `initTcForLookup` which was instrumental for
      the past version of `lookupGlobal`. This, in turn, called for pushing
      some more parts of the lookup interface from the `Tc`-monad to `IO`,
      most notably, adding `IO`-version of `lookupOrig` and pushing
      `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn,
      triggered a slight redesign of name cache updating interface: we now
      have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod`
      and `occ` to force them inside, instead of more error-prone outside
      before. But all these hardly have to do anything with #14391, mere
      refactoring.
      
      Reviewers: simonpj, nomeata, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14391
      
      Differential Revision: https://phabricator.haskell.org/D4503
      bb3fa2d1
  26. 14 May, 2018 1 commit
    • Herbert Valerio Riedel's avatar
      Add support for opting out of package environments · 8f3c149d
      Herbert Valerio Riedel authored
      This implements the first part proposed in #13753:
      
      Define a special magic "null" environment, which instructs GHC to ignore
      any package environment files. To this end, I propose to use the name
      `-` (i.e. a single dash), as that is more portable than using the empty
      string for environment variables. In other words, a
      
      - `-package-env -` CLI flag, or a
      - `GHC_ENVIRONMENT=-` env var (unless a `-package-env` flag is present)
      
      would inhibit GHC from looking up and interpreting any package
      environment files from the filesystem; this is the equivalent of
      `-ignore-dot-ghci` for package environment files.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13753
      
      Differential Revision: https://phabricator.haskell.org/D4690
      8f3c149d
  27. 13 May, 2018 2 commits
    • Matthew Pickering's avatar
      Simplify -ddump-json implementation · 6ab7cf99
      Matthew Pickering authored
      This patch takes the much simpler route of whenever the compiler tries
      to output something. We just dump a JSON document there and then.
      
      I think this should be sufficient to work with and anything more refined
      quickly got complicated as it was necessary to demarcate message scopes
      and so on.
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #14078
      
      Differential Revision: https://phabricator.haskell.org/D4532
      6ab7cf99
    • Herbert Valerio Riedel's avatar
      Emit info-level log message when package envs are loaded · 00049e2d
      Herbert Valerio Riedel authored
      A common complaint with the new package environment files feature is
      that it's not obvious when package environments have been picked up.
      This patch applies the same strategy that was already used for `.ghci` files
      (which exhibit similar potential for confusion, c.f. #11389) to package
      environment files.
      
      For instance, this new notification looks like below for a GHCi invocation which
      loads both, a GHCi configuration as well as a package environment:
      
        GHCi, version 8.5.20180512: http://www.haskell.org/ghc/  :? for help
        Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512
        Loaded GHCi configuration from /home/hvr/.ghci
        Prelude>
      
      Addresses #15145
      
      Reviewed By: bgamari, angerman
      
      GHC Trac Issues: #15145
      
      Differential Revision: https://phabricator.haskell.org/D4689
      00049e2d
  28. 12 May, 2018 1 commit
  29. 10 May, 2018 1 commit
  30. 09 May, 2018 1 commit
    • Simon Marlow's avatar
      Add -fghci-leak-check to check for space leaks · 5fe6aaa3
      Simon Marlow authored
      Summary:
      Space leaks in GHCi emerge from time to time and tend to come back again
      after they get fixed. This is an attempt to limit regressions by
      
      * adding a reliable detection for some classes of space leaks in GHCi
      * turning on leak checking for all GHCi tests in the test suite, so that
        we'll notice if the leak appears again.
      
      The idea for detecting space leaks is quite simple:
      
      * find some data that we expect to be GC'd later, make a weak pointer to it
      * when we expect the data to be dead, do a `performGC` and then check
        the status of the weak pointer.
      
      It would be nice to apply this trick to lots of things in GHC,
      e.g. ensuring that HsSyn is not retained after the desugarer, or
      ensuring that CoreSyn from the previous simplifier pass is not retained.
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, erikd, niteria
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15111
      
      Differential Revision: https://phabricator.haskell.org/D4658
      5fe6aaa3
  31. 16 Apr, 2018 1 commit