1. 26 Jan, 2017 14 commits
    • Daishi Nakajima's avatar
      Fix the right-shift operation for negative big integers (fixes #12136) · 06b9561a
      Daishi Nakajima authored
      In `x shiftR y`, any of the following conditions cause an abort:
      - `x` is a negative big integer
      - The size of `x` and `y` is a multiple of `GMP_NUMB_BITS`
      - The bit of the absolute value of `x` is filled with `1`
      For example:
      Assuming `GMP_NUMB_BITS = 2`,  the processing of `-15 shiftR 2` is as 
      1. -15 = -1111 (twos complement: 10001)
      2. right shift 2 (as a positive number) -> 0011
      3. Due to the shift larger than GMP_NUMB_BITS, the size of the 
      destination is decreasing (2bit) -> 11
      4. Add 1, and get carry: (1) 00
      5. abort
      I fixed it that the destination size does not decrease in such a case.
      Test Plan: I tested the specific case being reported.
      Reviewers: goldfire, austin, hvr, bgamari, rwbarton
      Reviewed By: bgamari, rwbarton
      Subscribers: mpickering, rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D2998
      GHC Trac Issues: #12136
    • Simon Marlow's avatar
      Fatal if we try to reinitialize the RTS · 2ffcdfad
      Simon Marlow authored
      This isn't supported, and fatalling with an error is better than
      segfaulting later.
      Test Plan: validate
      Reviewers: JonCoens, austin, erikd, niteria, bgamari
      Reviewed By: niteria, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D3020
    • Ben Gamari's avatar
      Bump hsc2hs submodule · 4e63e859
      Ben Gamari authored
    • Ben Gamari's avatar
      Bump nofib submodule · d8cb4b0d
      Ben Gamari authored
    • Dave Laing's avatar
      Generalizes the type of asProxyTypeOf (#12805) · 3eebd1f5
      Dave Laing authored
      Test Plan: validate
      Reviewers: austin, hvr, bgamari, RyanGlScott, simonpj
      Reviewed By: RyanGlScott, simonpj
      Subscribers: simonpj, RyanGlScott, thomie
      Differential Revision: https://phabricator.haskell.org/D3017
      GHC Trac Issues: #12805
    • Ryan Scott's avatar
      Don't unnecessarily qualify TH-converted instances with empty contexts · ad3d2dfa
      Ryan Scott authored
      The addition of rigorous pretty-printer tests
      (499e4382) had the unfortunate
      side-effect of revealing a bug in `hsSyn/Convert.hs` wherein instances are
      _always_ qualified with an instance context, even if the context is empty. This
      led to instances like this:
      instance Foo Int
      being pretty-printed like this!
      instance () => Foo Int
      We can prevent this by checking if the context is empty before adding an
      HsQualTy to the type.
      Also does some refactoring around HsForAllTys in `Convert` while I was in town.
      Fixes #13183.
      Test Plan: ./validate
      Reviewers: goldfire, bgamari, austin, alanz
      Reviewed By: alanz
      Subscribers: mpickering, thomie
      Differential Revision: https://phabricator.haskell.org/D3018
      GHC Trac Issues: #13183
    • Gabor Greif's avatar
      Prune unneeded Derive* language pragmas · 50544eea
      Gabor Greif authored
    • Alan Zimmerman's avatar
      Make type import/export API Annotation friendly · 0d1cb157
      Alan Zimmerman authored
      At the moment an export of the form
         type C(..)
      is parsed by the rule
        |  'type' oqtycon           {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2)))
                                           [mj AnnType $1,mj AnnVal $2] }
      This means that the origiinal oqtycon loses its location which is then retained
      in the AnnVal annotation.
      The problem is if the oqtycon has its own annotations, these get lost.
      e.g. in
        type (?)(..)
      the parens annotations for (?) get lost.
      This patch adds a wrapper around the name in the IE type to
      (a) provide a distinct location for the adornment annotation and
      (b) identify the specific adornment, for use in the pretty printer rather than
      occName magic.
      Updates haddock submodule
      Test Plan: ./validate
      Reviewers: mpickering, dfeuer, bgamari, austin
      Reviewed By: dfeuer
      Subscribers: dfeuer, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D3016
      GHC Trac Issues: #13163
    • Gabor Greif's avatar
      Typos in comments [ci skip] · ff9355e4
      Gabor Greif authored
    • Ryan Scott's avatar
      Nix typo and redundant where-clauses · 88a89b76
      Ryan Scott authored
    • Ryan Scott's avatar
      Add pragCompleteDName to templateHaskellNames · e4ab8ba7
      Ryan Scott authored
      95dc6dc0 forgot to add `pragCompleteDName`
      to the list of `templateHaskellNames`, which caused a panic if you actually
      tried to splice a `COMPLETE` pragma using Template Haskell. This applies the
      easy fix and augments the regression test to check for this in the future.
    • David Feuer's avatar
      Generalize the type of runRW# · c344005b
      David Feuer authored
      * Generalize the type of `runRW#` to allow arbitrary return types.
      * Use `runRW#` to implement `Control.Monad.ST.Lazy.runST` (this
      provides evidence that it actually works properly with the generalized
      * Adjust the type signature in the definition of `oneShot` to match
      the one it is given in `MkId`.
      Reviewers: simonmar, austin, bgamari, hvr
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D3012
      GHC Trac Issues: #13178
    • Matthew Pickering's avatar
      Template Haskell support for COMPLETE pragmas · 95dc6dc0
      Matthew Pickering authored
      Reviewers: RyanGlScott, austin, goldfire, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2997
      GHC Trac Issues: #13098
    • Matthew Pickering's avatar
      COMPLETE pragmas for enhanced pattern exhaustiveness checking · 1a3f1eeb
      Matthew Pickering authored
      This patch adds a new pragma so that users can specify `COMPLETE` sets of
      `ConLike`s in order to sate the pattern match checker.
      A function which matches on all the patterns in a complete grouping
      will not cause the exhaustiveness checker to emit warnings.
      pattern P :: ()
      pattern P = ()
      {-# COMPLETE P #-}
      foo P = ()
      This example would previously have caused the checker to warn that
      all cases were not matched even though matching on `P` is sufficient to
      make `foo` covering. With the addition of the pragma, the compiler
      will recognise that matching on `P` alone is enough and not emit
      any warnings.
      Reviewers: goldfire, gkaracha, alanz, austin, bgamari
      Reviewed By: alanz
      Subscribers: lelf, nomeata, gkaracha, thomie
      Differential Revision: https://phabricator.haskell.org/D2669
      GHC Trac Issues: #8779
  2. 25 Jan, 2017 4 commits
  3. 24 Jan, 2017 15 commits
  4. 23 Jan, 2017 7 commits
    • niteria's avatar
      Make tickishContains faster · 532c6ade
      niteria authored
      This just reorders some inequality checks to make the common case
      The results are quite dramatic for #11095, but that's probably because
      something else is causing it to do too much work.
      Before (full https://phabricator.haskell.org/P136):
        13,589,495,832 bytes allocated in the heap
      After (full https://phabricator.haskell.org/P137):
         7,885,575,872 bytes allocated in the heap
      This is with `BuildFlavour = devel2`, so take it with a
      a grain of salt.
      For reference, with no `-g` I get:
      155,703,112 bytes allocated in the heap
      so we're still quite a way off.
      Test Plan:
      I still have to test locally
      Reviewers: austin, bgamari
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D3001
      GHC Trac Issues: #11095
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 596dece7
      Simon Peyton Jones authored
      This patch is a refinement of the original commit (which
      was reverted):
        commit 6b976eb8
        Date:   Fri Jan 13 08:56:53 2017 +0000
            Record evaluated-ness on workers and wrappers
      In Trac #13027, comment:20, I noticed that wrappers created after
      demand analysis weren't recording the evaluated-ness of strict
      constructor arguments.  In the ticket that led to a (debatable)
      Lint error but in general the more we know about evaluated-ness
      the better we can optimise.
      This commit adds that info
        * both in the worker (on args)
        * and in the wrapper (on CPR result patterns).
      See Note [Record evaluated-ness in worker/wrapper] in WwLib
      On the way I defined Id.setCaseBndrEvald, and used it to shorten
      the code in a few other places
      Then I added test T13077a to test the CPR aspect of this patch,
      but I found that Lint failed!
      Reason: simpleOptExpr was discarding evaluated-ness info on
      lambda binders because zapFragileIdInfo was discarding an
      Unfolding of (OtherCon _).  But actually that's a robust
      unfolding; there is no need to discard it. To fix this:
      * zapFragileIdInfo only zaps fragile unfoldings
      * Replace isClosedUnfolding with isFragileUnfolding (the latter
        is just the negation of the former, but the nomenclature is
        more consistent).  Better documentation too
             Note [Fragile unfoldings]
      * And Simplify.simplLamBndr can now look at isFragileUnfolding
        to decide whether to use the longer route of simplUnfolding.
      For some reason perf/compiler/T9233 improves in compile-time
      allocation by 10%.  Hooray
      Nofib: essentially no change:
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
            cacheprof          +0.0%     -0.3%     +0.9%     +0.4%     +0.0%
                  Min          +0.0%     -0.3%     -2.4%     -2.4%     +0.0%
                  Max          +0.0%     +0.0%     +9.8%    +11.4%     +2.4%
       Geometric Mean          +0.0%     -0.0%     +1.1%     +1.0%     +0.0%
    • Ryan Scott's avatar
      Don't quantify implicit type variables when quoting type signatures in TH · 729a5e45
      Ryan Scott authored
      A bug was introduced in GHC 8.0 in which Template Haskell-quoted type
      signatures would quantify _all_ their type variables, even the implicit ones.
      This would cause splices like this:
      $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a
            idProxy x = x
      To splice back in something that was slightly different:
      idProxy :: forall k proxy (a :: k). proxy a -> proxy a
      idProxy x = x
      Notice that the kind variable `k` is now explicitly quantified! What's worse,
      this now requires the `TypeInType` extension to be enabled.
      This changes the behavior of Template Haskell quoting to never explicitly
      quantify type variables which are implicitly quantified in the source.
      There are some other places where this behavior pops up too, including
      class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports,
      and pattern synonynms (#13018), so I fixed those too.
      Fixes #13018 and #13123.
      Test Plan: ./validate
      Reviewers: simonpj, goldfire, austin, bgamari
      Reviewed By: simonpj, goldfire
      Subscribers: simonpj, mpickering, thomie
      Differential Revision: https://phabricator.haskell.org/D2974
      GHC Trac Issues: #13018, #13123
    • niteria's avatar
      Make checkFamInstConsistency faster · 18ceb148
      niteria authored
      We've noticed that `checkFamInstConsistency` takes 6% of
      overall build time on our codebase.
      I've poked around for a bit and most of type family
      instances are `Rep` from `Generics`. I think those are
      unavoidable, so I don't think we can have less of them.
      I also looked at the code and noticed a simple algorithmic
      improvement can be made. The algorithm is pretty simple:
      we take all the family instances from one module (`M1`)
      and test it against another module (`M2`).
      The cost of that is dominated by the size of `M1`, because
      for each instance in `M1` we look it up in the type family
      env from `M2`, and lookup is cheap.
      If `M1` is bigger than `M2`, that's suboptimal, so after
      my change we always iterate through the smaller set.
      This drives down the cost of `checkFamInstConsistency`
      to 2%.
      Test Plan: harbormaster
      Reviewers: simonmar, simonpj, goldfire, rwbarton, bgamari, ezyang, austin
      Reviewed By: rwbarton, ezyang
      Subscribers: ezyang, thomie
      Differential Revision: https://phabricator.haskell.org/D2833
    • Gabor Greif's avatar
      Typos and grammar in manual/comments · 80560e69
      Gabor Greif authored
    • Simon Peyton Jones's avatar
      Apply the right substitution in ty-fam improvement · 2b64e926
      Simon Peyton Jones authored
      Trac #13135 showed that we were failing to apply the
      correct substitution to the un-substituted tyvars during
      type-family improvement using injectivity.  Specifically
      in TcInteractlinjImproveEqns we need to use instFlexiX.
      An outright bug, easy to fix.
      Slight refactoring along the way.  The quantified tyars of the axiom are
      readily to hand; we don't need to take the free tyvars of the LHS
    • Simon Peyton Jones's avatar
      Improve pretty-printing of IfaceCoercions · 6850eb64
      Simon Peyton Jones authored
      For some reason, unless you have -fprint-explicit-coercions, when
      printing an explicit coercion we were then going to special trouble to
      suppress the unique of a hole (which only happens during debugging
      anyway).  This is bizarre.
      So I deleted three lines of code -- hooray.