1. 01 Oct, 2016 5 commits
    • tmcgilchrist's avatar
      Recognise US spelling for specialisation flags. · 151edd89
      tmcgilchrist authored and Ben Gamari's avatar Ben Gamari committed
      The user guide says that we allow the user to use `specialise` or
      `specialize` interchangeably but this wasn't the case for the relevant
      flags. This patch adds aliases for the flags which control
      Reviewers: erikd, austin, mpickering, bgamari
      Reviewed By: mpickering, bgamari
      Subscribers: mpickering, thomie
      Differential Revision: https://phabricator.haskell.org/D2542
      GHC Trac Issues: #12575
    • Tamar Christina's avatar
      Support more than 64 logical processors on Windows · 3c179054
      Tamar Christina authored and Ben Gamari's avatar Ben Gamari committed
      Windows support for more than 64 logical processors are implemented
      using processor groups.
      Essentially what it's doing is keeping the existing maximum of 64
      processors and keeping the affinity mask a 64 bit value, but adds an
      hierarchy above that.
      This support was added to Windows 7 and so we need to at runtime detect
      if the APIs are still there due to our minimum supported version being
      Windows Vista.
      The Maximum number of groups supported at this time is 4, so 256 logical
      cores.  The group indices are 0 based. One thread can have affinity with
      multiple groups.
      and particularly helpful is the whitepaper: 'Supporting Systems that
      have more than 64 processors' at
      Processor groups are not guaranteed to be uniformly distributed nor
      guaranteed to be filled before a next group is needed. The OS will
      assign processors to groups based on physical proximity and will never
      partially assign cores from one physical cpu to more than one group. If
      one has two 48 core CPUs then you'd end up with two groups of 48 logical
      cpus. Now add a 3rd CPU with 10 cores and the group it is assigned to
      depends where the socket is on the board.
      Test Plan:
      ./validate or make test -c . in the rts test folder.
      This tests for regressions, to test this particular functionality
         <program> +RTS -N -qa -RTS
      Test is detailed in description.
      Reviewers: bgamari, simonmar, austin, erikd
      Reviewed By: simonmar
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2533
      GHC Trac Issues: #11054
    • mniip's avatar
      GHCi: Don't remove shadowed bindings from typechecker scope. · 59d7ee53
      mniip authored and Ben Gamari's avatar Ben Gamari committed
      The shadowed out bindings are accessible via qualified names like
      Ghci1.foo.  Since they are accessable in the renamer the typechecker
      should be able to see them too.  As a consequence they show up in :show
      This fixes T11547
      Test Plan:
      Fixed current tests to accomodate to new stuff in :show bindings
      Added a test that verifies that the typechecker doesn't crash
      Reviewers: austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D2447
      GHC Trac Issues: #11547
    • Sylvain HENRY's avatar
      CodeGen X86: fix unsafe foreign calls wrt inlining · b61b7c24
      Sylvain HENRY authored and Ben Gamari's avatar Ben Gamari committed
      Foreign calls (unsafe and safe) interact badly with inlining and
      register passing ABIs (see #11792 and #12614):
      the inlined code to compute a parameter of the call may overwrite a
      register already set to pass a preceding parameter.
      With this patch, we compute all parameters which are not simple
      expressions before assigning them to fixed registers required by the
      Test Plan:
         - Add test (test both reg and stack parameters)
         - Validate
      Reviewers: osa1, bgamari, austin, simonmar
      Reviewed By: simonmar
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2263
      GHC Trac Issues: #11792, #12614
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      Fixes #10598. Updates haddock submodule.
      Test Plan: ./validate
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      Reviewed By: alanz, bgamari, simonpj
      Subscribers: thomie, mpickering, oerjan
      Differential Revision: https://phabricator.haskell.org/D2280
      GHC Trac Issues: #10598
  2. 30 Sep, 2016 10 commits
    • Ryan Scott's avatar
      Document Safe Haskell restrictions on Generic instances · b3d55e20
      Ryan Scott authored
      Commit 578fbeca disallowed hand-written
      `Generic` instances in Safe Haskell, but this wasn't documented anywhere.
    • Gabor Greif's avatar
      Correct spelling in note references · 28a00eaf
      Gabor Greif authored
    • Simon Peyton Jones's avatar
      Make tcrun042 fail · 3f27237b
      Simon Peyton Jones authored
      This test uses wholesale impredicative polymorphism, and now fails.
      That's ok.
    • Simon Peyton Jones's avatar
      Add missing stderr file · 5d473cd6
      Simon Peyton Jones authored
      ..accidentally omitted from previous commit.
    • Simon Peyton Jones's avatar
      Comments only · fc4ef667
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
    • Simon Peyton Jones's avatar
      Add Outputable Report in TcErrors · 3012c431
      Simon Peyton Jones authored
      ...just for debug output
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 66a8c194
      Simon Peyton Jones authored
      1. Trac #12593 exposed a long-standing bug in the occurs
         checking machinery.  When unifying two type variables
                a ~ b
         where a /= b, we were assuming that there could be
         no occurs-check error.  But there can: 'a' can occur
         in b's kind!  When the RHS was a non-tyvar we used
         occurCheckExpand, which /did/ look in kinds, but not
         when the RHS was a tyvar.
         This bug has been lurking ever since TypeInType, maybe
         longer.  And it was present both in TcUnify (the on-the-fly
         unifier), and in TcInteract.
         I ended up refactoring both so that the tyvar/tyvar
         path naturally goes through the same occurs-check as
         non-tyvar rhss.  It's simpler and more robust now.
         One good thing is that both unifiers now share
         previously they had different logic for the same goals
      2. Fixing this bug exposed another!  In T11635 we end
         up unifying
         (alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
         Now that the occurs check is done for tyvars too, we
         look inside beta's kind.  And then reject the program
         becuase of the forall inside there.  But in fact that
         forall is fine -- it does not count as impredicative
         polymoprhism.   See Note [Checking for foralls]
         in TcType.
      3. All this fuss around occurrence checking forced me
         to look at TcUnify.checkTauTvUpdate
                and TcType.occurCheckExpand
         There's a lot of duplication there, and I managed
         to elminate quite a bit of it. For example,
         checkTauTvUpdate called a local 'defer_me'; and then
         called occurCheckExpand, which then used a very
         similar 'fast_check'.
         Things are better, but there is more to do.
    • Simon Peyton Jones's avatar
      Fix desugaring of pattern bindings (again) · 2fbfbca2
      Simon Peyton Jones authored
      This patch fixes Trac #12595.  The problem was with a
      pattern binding like
           !x = e
      For a start it's silly to match that pattern and build
      a unit tuple (the General Case of mkSelectorBinds); but
      that's what was happening because the bang fell through
      to the general case.  But for a variable pattern building
      any auxiliary bindings is stupid.  So the patch
      introduces a new case in mkSelectorBinds for variable
      Then it turned out that if 'e' was a plain variable, and
      moreover was imported GlobalId, then matchSinglePat made
      it a /bound/ variable, which should never happen.  That
      ultimately caused a linker error, but the original bug
      was much earlier.
    • Simon Peyton Jones's avatar
      A bit of tracing about flattening · 0b533a25
      Simon Peyton Jones authored
  3. 29 Sep, 2016 2 commits
  4. 28 Sep, 2016 1 commit
  5. 27 Sep, 2016 1 commit
  6. 26 Sep, 2016 3 commits
  7. 24 Sep, 2016 3 commits
  8. 23 Sep, 2016 5 commits
    • Matthew Pickering's avatar
      Mark mapUnionFV as INLINABLE rather than INLINE · d1229353
      Matthew Pickering authored
      It is a self-recursive function so will always be the loop-breaker
      and hence never able to be inlined. It is dubious whether the INLINABLE
      pragma will ever help as it is not a very polymorphic function
      but some specialisation could occur.
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      At use sites, I went through and chose the unification function
      according to the criteria above.
      This patch includes some modest performance improvements as we
      are now doing less work.
    • Simon Marlow's avatar
      Improved documentation for Foreign.Concurrent (#12547) · 3a17916b
      Simon Marlow authored
      We had better docs for the underlying functions in GHC.ForeignPtr, but
      this wasn't propagated to the re-exported versions in
    • Simon Marlow's avatar
      Expose hs_exit_(rtsFalse) as hs_exit_nowait() · 74c4ca02
      Simon Marlow authored
      Summary: And document it.  See the docmentation for the reason I want this.
      Test Plan: It's an existing API, just exposing it.
      Reviewers: bgamari, niteria, austin, erikd
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2531
    • Simon Marlow's avatar
      shutdownHaskellAndExit: just do a normal hs_exit() (#5402) · 9cbcdb48
      Simon Marlow authored
      If we want to keep the RTS alive a bit longer by having another
      hs_init()/hs_exit() pair in a library that will destruct itself after
      main() has exited, then the forced shutdown here thwarts that.
      I think we just "fixed" #5402 in the wrong way before, this should be
  9. 21 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Fix failing test T12504 · 8bd3d417
      Tamar Christina authored
      Test T12504 does it's checking in the Makefile using grep but still specified an stdout.
      the stdout has the old output and would always fail.
      Since the stdout isn't needed, let's not check it.
      Test Plan: make test TEST=T12504
      Reviewers: bgamari, austin, erikd, rcook
      Reviewed By: rcook
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2537
      GHC Trac Issues: #12504
  10. 20 Sep, 2016 2 commits
  11. 16 Sep, 2016 1 commit
    • Ben Gamari's avatar
      Remove directories from include paths · ea310f99
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Previously this was a relative path which worked in the GHC tree, but
      failed elsewhere. This caused trouble for out-of-tree users as well as
      Hadrian, which wants to move build artifacts out of the working
      directory. Fixes #8040.
      Test Plan: Validate
      Reviewers: thomie, austin, snowleopard, hvr
      Reviewed By: snowleopard, hvr
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2530
      GHC Trac Issues: #8040
  12. 15 Sep, 2016 6 commits