1. 11 Mar, 2015 2 commits
  2. 10 Mar, 2015 8 commits
  3. 09 Mar, 2015 9 commits
  4. 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
  5. 06 Mar, 2015 4 commits
  6. 05 Mar, 2015 3 commits
  7. 04 Mar, 2015 1 commit