1. 10 Mar, 2015 6 commits
  2. 09 Mar, 2015 9 commits
  3. 07 Mar, 2015 13 commits
    • Herbert Valerio Riedel's avatar
      Add `GHC.OldList` legacy module · e76f8664
      Herbert Valerio Riedel authored
      This module provides access the list-specialised versions for legacy purposes
      (such as implementing Haskell2010-ish preludes). This module basically
      re-exports the hidden `Data.OldList` module (but in the less controversial `GHC.*`
      namespace, which signals less committment to keep this module around).
      
      This is legacy module is mostly for GHC 7.10's sake. What becomes long-term
      of `GHC.OldList` can be decided unhurriedly during the GHC 7.12 development
      cycle.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D689
      e76f8664
    • Herbert Valerio Riedel's avatar
      Define proper `MINIMAL` pragma for `class Ix` · 7a2d65a4
      Herbert Valerio Riedel authored
      Summary: This addresses #10142
      
      Reviewers: goldfire, austin, ekmett
      
      Reviewed By: austin, ekmett
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D709
      
      GHC Trac Issues: #10142
      7a2d65a4
    • Herbert Valerio Riedel's avatar
      base: drop redundant Typeable derivings · 47b5b5c2
      Herbert Valerio Riedel authored
      Thanks to #9858 `Typeable` doesn't need to be explicitly derived anymore.
      This also makes `AutoDeriveTypeable` redundant, as well as some imports of
      `Typeable` (removal of whose may be beneficial to #9707). This commit
      removes several such now redundant use-sites in `base`.
      
      Reviewed By: austin, ekmett
      
      Differential Revision: https://phabricator.haskell.org/D712
      47b5b5c2
    • Edward Z. Yang's avatar
      Store renamings as (ModuleName, ModuleName) pairs. · 68d4f472
      Edward Z. Yang authored
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D710
      68d4f472
    • Austin Seipp's avatar
      build: fix 'make help' · e642de62
      Austin Seipp authored
      
      
      Summary:
      This fixes the usage of `make help` in the top-level and subdirectories.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: It worked now and didn't before.
      
      Reviewers: hvr
      
      Reviewed By: hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D692
      e642de62
    • Peter Trommler's avatar
      Dynamically link all loaded packages in new object · 0fcc4543
      Peter Trommler authored
      Summary:
      As a result of fixing #8935 we needed to open shared libraries
      with RTLD_LOCAL and so symbols from packages loaded earlier
      cannot be found anymore. We need to include in the link all
      packages loaded so far.
      
      This fixes #10058
      
      Test Plan: validate
      
      Reviewers: hvr, simonmar, austin
      
      Reviewed By: austin
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D676
      
      GHC Trac Issues: #10058
      0fcc4543
    • Alexander Vershilov's avatar
      Improve core linter so it catches unsafeCoerce problems (T9122) · 76b1e119
      Alexander Vershilov authored
      Summary:
      This is a draft of the patch that is sent for review.
      
      In this patch required changes in linter were introduced
      and actual check:
      
       - new helper function: primRepSizeB
       - primRep check for floating
       - Add access to dynamic flags in linter.
       - Implement additional lint rules.
      
      Reviewers: austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D637
      
      GHC Trac Issues: #9122
      76b1e119
    • Rufflewind's avatar
      Don't assume tools are in same directory as ghc in some cases · 504d8a4b
      Rufflewind authored
      Summary: Tools such as `ghc-pkg` and `runghc` are no longer required to be in the same directory as `ghc` when running tests, provided that `TEST_HC` is not explicitly set and an in-tree compiler is not used.  Fixes #10126.
      
      Reviewers: thomie, austin
      
      Reviewed By: thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D705
      
      GHC Trac Issues: #10126
      504d8a4b
    • Austin Seipp's avatar
      Add missed test (uuugh) · 34ba68c2
      Austin Seipp authored
      
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      34ba68c2
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      Summary:
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      
      The current implementation creates `TyCon` representations on the spot.
      
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      
      Reviewers: simonpj, simonmar, austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D652
      
      GHC Trac Issues: #9858
      b359c886
    • Herbert Valerio Riedel's avatar
      Re-export `<$` from Prelude (#10113) · 479523f3
      Herbert Valerio Riedel authored
      This is a follow-up to eb3661f2
      re-exporting `<$` from `Prelude` as well.
      
      Reviewed By: austin, ekmett
      
      Differential Revision: https://phabricator.haskell.org/D681
      479523f3
    • Herbert Valerio Riedel's avatar
      Re-export `<$>` from Prelude (#10113) · eb3661f2
      Herbert Valerio Riedel authored
      Whether to re-export the `<$>` non-method operator from `Prelude` wasn't
      explicitly covered in the original AMP proposal[1], but it turns out that
      not doing so forces most code that makes use of applicatives to import
      `Data.Functor` or `Control.Applicative` just to get that operator into
      scope.  To this end, it was proposed to add `<$>` to Prelude as well[2].
      
      The down-side is that this increases the amount of redundant-import
      warnings triggered, as well as the relatively minor issue of stealing
      the `<$>` operator from the default namespace for good (although at this
      point `<$>` is supposed to be ubiquitous anyway due to `Applicative`
      being implicitly required into the next Haskell Report)
      
       [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
       [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161
      
      Reviewed By: austin, ekmett
      
      Differential Revision: https://phabricator.haskell.org/D680
      eb3661f2
    • Herbert Valerio Riedel's avatar
      Drop redundant LANGUAGE pragmas · 1965202f
      Herbert Valerio Riedel authored
      Due to refactoring & cleanups those pragmas have become redundant by now
      1965202f
  4. 06 Mar, 2015 4 commits
  5. 05 Mar, 2015 3 commits
  6. 04 Mar, 2015 5 commits
    • thomie's avatar
      Remove unused/undocumented flag `-fhpc-no-auto` · 8a5d3205
      thomie authored
      Added in 53a5d0b0. Perhaps accidentally? It didn't do anything back then
      either.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D700
      8a5d3205
    • Joachim Breitner's avatar
      e73c0dea
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Check for equality before deferring · 3aa2519e
      Simon Peyton Jones authored
      This one was a bit of a surprise. In fixing Trac #7854, I moved
      the checkAmbiguity tests to checkValidType. That meant it happened
      even for monotypes, and that turned out to be very expensive in
      T9872a, for reasons described in this (new) Note in TcUnify:
      
          Note [Check for equality before deferring]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Particularly in ambiguity checks we can get equalities like (ty ~ ty).
          If ty involves a type function we may defer, which isn't very sensible.
          An egregious example of this was in test T9872a, which has a type signature
                 Proxy :: Proxy (Solutions Cubes)
          Doing the ambiguity check on this signature generates the equality
             Solutions Cubes ~ Solutions Cubes
          and currently the constraint solver normalises both sides at vast cost.
          This little short-cut in 'defer' helps quite a bit.
      
      I fixed the problem with a quick equality test, but it feels like an ad-hoc
      solution; I think we might want to do something in the constraint solver too.
      
      (The problem was there all along, just more hidden.)
      3aa2519e
    • Simon Peyton Jones's avatar
      Comments only · ef2c7a73
      Simon Peyton Jones authored
      ef2c7a73