1. 17 Oct, 2016 6 commits
    • Simon Peyton Jones's avatar
      Fix wrapping order in matchExpectedConTy · f7278a90
      Simon Peyton Jones authored
      The wrappers in matchExpectedConTy were being composed back
      to front, resulting in a Core Lint error.  Yikes!  This has
      been here a long time.
      Fixes Trac #12676.
    • Simon Peyton Jones's avatar
      Correct order of existentials in pattern synonyms · a693d1cb
      Simon Peyton Jones authored
      Trac #12698 exposed a nasty bug in the typechecking for
      pattern synonmys: the existential type variables weren't
      being put in properly-scoped order.
      For some reason TcPatSyn.tcCollectEx was colleting them as a
      set, not as a list!  Easily fixed.
    • Simon Peyton Jones's avatar
      Typo in comment · 609d2c81
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix shadowing in mkWwBodies · 692c8df0
      Simon Peyton Jones authored
      This bug, exposed by Trac #12562 was very obscure, and has been
      lurking for a long time.  What happened was that, in the
      worker/wrapper split
        a tyvar binder for a worker function
        accidentally shadowed an in-scope term variable
        that was mentioned in the body of the function
      It's jolly hard to provoke, so I have not even attempted to make
      a test case.  There's a Note [Freshen WW arguments] to explain.
      Interestingly, fixing the bug (which meant fresher type variables)
      revealed a second lurking bug: I'd failed to apply the substitution to
      the coercion in the second last case of mkWWArgs, which introduces a
    • Simon Peyton Jones's avatar
      Fix comment typo · 82b54fcf
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
  2. 16 Oct, 2016 1 commit
  3. 15 Oct, 2016 3 commits
  4. 14 Oct, 2016 10 commits
    • Michael Snoyman's avatar
      Disable T-signals-child test on single-threaded runtime · 0d9524a8
      Michael Snoyman authored
      As identified by Joachim, this test broke the Travis build. It appears
      that this is due to the usage of the single-threaded runtime there. I've
      confirmed that this fix causes the Travis build to pass:
      Test Plan: Confirm tests now pass
      Reviewers: austin, nomeata, bgamari
      Reviewed By: nomeata, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2593
    • Sylvain HENRY's avatar
      Check for empty entity string in "prim" foreign imports · 6c739326
      Sylvain HENRY authored
      Foreign imports with "prim" convention require a valid symbol identifier
      (see linked issue). We check this.
      Fix line too long
      Test Plan: Validate
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2563
      GHC Trac Issues: #12355
    • Simon Marlow's avatar
      Build ghc-iserv with --export-dynamic · 3ce0e0ba
      Simon Marlow authored
      This enables loading dynamic libraries that refer to the RTS.  I just
      came across somewhere I needed to do that, and without
      `--export-dynamic` it's impossible.
      For now we'll only support that when using `-fexternal-interpreter`,
      because the dynamic symbol table for GHC itself is much bigger.
      Test Plan: validate
      Reviewers: niteria, austin, erikd, bgamari
      Reviewed By: bgamari
      Subscribers: Phyx, thomie
      Differential Revision: https://phabricator.haskell.org/D2590
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored
      Before, when you attempted to derive an instance for a typeclass,
      class C1 (a :: Constraint) where
      class C2 where
      deriving instance C1 C2
      GHC would complain that `C2`'s data constructors aren't in scope. But
      makes no sense, since typeclasses don't have constructors! By refining
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      Fixes #11509.
      Test Plan: make test TEST=T11509
      Reviewers: simonpj, austin, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D2558
      GHC Trac Issues: #11509
    • Ryan Scott's avatar
      Add missing Semigroup instances for Monoidal datatypes in base · 8c6a3d68
      Ryan Scott authored
      There are currently three datatypes that are exposed in `base` that have
      `Monoid` instances, but no `Semigroup` instances:
      * `IO`
      * `Event` (from `GHC.Event`)
      * `Lifetime` (from `GHC.Event`)
      (There is also `EventLifetime` in `GHC.Event.Internal`, but it is not exported
      directly, so I didn't bother with it.)
      Adding the `Semigroup` instances for these types directly in the modules in
      which they're defined resulted in some horrific import cycles, so I opted to
      take the easy approach of defining all of these instances in `Data.Semigroup`.
      (When `Semigroup` becomes a superclass of `Monoid`, these instances will have
      to be moved somehow.)
      Fixes #12464.
      Test Plan: It compiles
      Reviewers: hvr, ekmett, austin, bgamari
      Reviewed By: ekmett
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2588
      GHC Trac Issues: #12464
    • Ben Gamari's avatar
      PrelInfo: Fix style · 90df91a0
      Ben Gamari authored
    • Ben Gamari's avatar
      Improve find_lbl panic message · aa06883c
      Ben Gamari authored
    • Ben Gamari's avatar
      MkIface: Turn a foldr into a foldl' · 3991da46
      Ben Gamari authored
      There is no reason why this should be a foldr considering we are
      building a map.
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      This had a surprising number of knock-on effects,
       * constraint tuple datacons had to be made known-key (previously they
         were not)
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
       * Lots of comments were sprinkled about describing the new scheme.
      Updates haddock submodule.
      Test Plan: Validate
      Reviewers: niteria, simonpj, austin, hvr
      Reviewed By: simonpj
      Subscribers: simonmar, niteria, thomie
      Differential Revision: https://phabricator.haskell.org/D2467
      GHC Trac Issues: #12532, #12415
    • Ben Gamari's avatar
      Unique: Simplify encoding of sum uniques · 1cccb646
      Ben Gamari authored
      The previous encoding was entropically a bit better, but harder to
      encode and decode. Now we just split up the integer part of the unique
      into a bitfield.
      Test Plan: Validate
      Reviewers: austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2468
  5. 13 Oct, 2016 4 commits
  6. 12 Oct, 2016 6 commits
  7. 11 Oct, 2016 2 commits
    • Joachim Breitner's avatar
      Add a broken test case for #12689 · f8d2c205
      Joachim Breitner authored
      A rule with a phase specification trying to match on a constructor with
      a wrapper will fail to match, as the wrapper will be inlined by then.
      The fact that it works in the other case is also mostly by accident.
      (Split into two test cases so that regressions with regard what works so
      far are caught.)
    • Joachim Breitner's avatar
      Add test case for #12689 · b5be2ec3
      Joachim Breitner authored
      which test a few variants of rules involving constructors, including
      nullary constructors, constructors with wrappers, and unsaturated of
      At the moment, all the rules work as expected, despite GHC’s compile
      time warnings when called with -Wall.
  8. 10 Oct, 2016 6 commits
    • Simon Peyton Jones's avatar
      More tests for Trac #12522 · a6111b8c
      Simon Peyton Jones authored
      These ones test the variations in coment:15 of the ticket
    • Simon Peyton Jones's avatar
      Improved stats for Trac #1969 · cc5ca21b
      Simon Peyton Jones authored
      With my latest commits
        76a5477b Move zonking out of tcFamTyPats
        b255ae7b Orient improvement constraints better
      perf has improved slightly for T1969:
      allocs:    733M -> 26M
      residency: 43M  -> 41M
      I don't know exactly why, but hey, it's good
    • Simon Peyton Jones's avatar
      Move zonking out of tcFamTyPats · 76a5477b
      Simon Peyton Jones authored
      In tcFamTyPats we were zonking from the TcType world to the
      Type world, ready to build the results into a CoAxiom (which
      should have no TcType stuff.  But the 'thing_inside' for
      tcFamTyPats also must be zonked, and that zonking must have
      the ZonkEnv from the binders zonked tcFamTyPats.
      Ugh.  This caused an assertion failure (with DEBUG on) in
      RaeBlobPost and TypeLevelVec, both in tests/dependent, as
      shown in Trac #12682.  Why it hasn't shown up before now
      is obscure to me.
      So I moved the zonking stuff out of tcFamTyPats to its
      three call sites, where we can do it all together. Very
      slightly longer, but much more robust.
    • Simon Peyton Jones's avatar
      Delete orphan where clause · 88eb7738
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Rename a parameter; trivial refactor · b5c89636
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Orient improvement constraints better · b255ae7b
      Simon Peyton Jones authored
      This patch fixes an infinite loop in the constraint solver,
      shown up by Trac #12522.
      The solution is /very/ simple: just reverse the orientation of the
      derived constraints arising from improvement using type-family
      injectivity.  I'm not very proud of the fix --- it seems fragile
      --- but it has the very great merit of simplicity, and it works
      See Note [Improvement orientation] in TcInteract, and some
      discussion on the Trac ticket.
  9. 09 Oct, 2016 2 commits
    • Vaibhav Sagar's avatar
      Escape lambda. · 1a9705c3
      Vaibhav Sagar authored
      Test Plan: View updated documentation?
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2583
      GHC Trac Issues: #12672
    • Simon Marlow's avatar
      Turn on -n4m with -A16m or greater · 85e81a85
      Simon Marlow authored
      Nursery chunks help reduce the cost of GC when capabilities are unevenly
      loaded, by ensuring that we use more of the available nursery.
      The rationale for enabling this at -A16m is that any negative effects
      due to loss of cache locality are less likely to be an issue at -A16m
      and above.  It's a conservative guess.  If we had a lot of benchmark
      data we could probably do better.
      Results for nofib/parallel at -N4 -A32m with and without -n4m:
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
         blackscholes           0.0%     -9.5%     -9.0%    -15.0%     -2.2%
                coins           0.0%     -4.7%     -3.6%     -0.6%    -13.6%
               mandel           0.0%     -0.3%     +7.7%    +13.1%     +0.1%
              matmult           0.0%     +1.5%    +10.0%     +7.7%     +0.1%
                nbody           0.0%     -4.1%     -2.9%     0.085      0.0%
               parfib           0.0%     -1.4%     +1.0%     +1.5%     +0.2%
              partree           0.0%     -0.3%     +0.8%     +2.9%     -0.8%
                 prsa           0.0%     -0.5%     -2.1%     -7.6%      0.0%
               queens           0.0%     -3.2%     -1.4%     +2.2%     +1.3%
                  ray           0.0%     -5.6%    -14.5%     -7.6%     +0.8%
             sumeuler           0.0%     -0.4%     +2.4%     +1.1%      0.0%
                  Min           0.0%     -9.5%    -14.5%    -15.0%    -13.6%
                  Max           0.0%     +1.5%    +10.0%    +13.1%     +1.3%
       Geometric Mean          +0.0%     -2.6%     -1.3%     -0.5%     -1.4%
      Not conclusive, but slightly better.  This matters a lot more when you
      have more cores.
      Test Plan: validate, nofib/paralel
      Reviewers: niteria, ezyang, nh2, trofi, austin, erikd, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2581
      GHC Trac Issues: #9221