This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 05 Mar, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Add public rnf/hash operations to TypeRep/TyCon · 56e0ac98
      Herbert Valerio Riedel authored
      Summary:
      `TyCon` and `TypeRep` are supposed to be abstract, by providing these
      additional few public operations the need to import
      `Data.Typeable.Internal` is reduced, and future changes to the internal
      structure of `TypeRep`/`TyCon` shouldn't require changes in packages such as
      `deepseq` or `hashable` anymore (hopefully).
      
      Reviewers: ekmett, simonpj, tibbe, austin
      
      Reviewed By: ekmett, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D699
      56e0ac98
  2. 04 Mar, 2015 9 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
    • Simon Peyton Jones's avatar
      A raft of small changes associated with -XConstrainedClassMethods · f66e0e69
      Simon Peyton Jones authored
      See Trac #7854.  Specifically:
      
      * Major clean up and simplification of check_op in checkValidClass;
        specifically
           - use checkValidType on the entire method-selector type to detect
             ambiguity
           - put a specific test for -XConstrainedClassMethods
      
      * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses
        (a bit ad-hoc but see #7854), and document in the user manual.
      
      * Do the checkAmbiguity test just once in TcValidity.checkValidType,
        rather than repeatedly at every level. See Note [When to call checkAmbiguity]
      
      * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous.
        (It's a rather magic function.)
      
      * Improve location info for check_op in checkValidClass
      
      * Update quite a few tests, which had genuinely-ambiguous class
        method signatures.  Some I fixed by making them unambiguous; some
        by adding -XAllowAmbiguousTypes
      f66e0e69
    • Simon Peyton Jones's avatar
      Some minor refactoring in TcHsType · d058bc9c
      Simon Peyton Jones authored
      d058bc9c
    • Simon Peyton Jones's avatar
      Tidy up and improve comments about one-shot info · ee56dc56
      Simon Peyton Jones authored
      (Triggered by investigating Trac #10102 etc.)
      ee56dc56
    • Tamar Christina's avatar
      Fix -Werror build failure in RtsMain · e673b840
      Tamar Christina authored
      Summary:
      Something in Excn.h's include chain is loading _mingw.h which is defining a macro that
      PosixSource.h is going to define.
      
      _mingw.h's version properly checks if it has already been defined and skips it, so fixing the warning can be done
      by just including Excn.h later (moved it to before last include).
      
      Test Plan: ./validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D698
      e673b840
  3. 03 Mar, 2015 5 commits
    • Edward Z. Yang's avatar
      6e77d45b
    • eir@cis.upenn.edu's avatar
      Don't use deriveUnique *twice* in flattenTys. · a0cea7ba
      eir@cis.upenn.edu authored
      Previously, we used deriveUnique and then uniqAway. This worked
      doubly hard to avoid clashes. Doing just uniqAway is enough.
      
      This commit also includes clarifying comments.
      a0cea7ba
    • Oleg Grenrus's avatar
      Add various instances to newtypes in Data.Monoid · 4e6bcc2c
      Oleg Grenrus authored
      Summary:
      Add Functor instances for Dual, Sum and Product
      Add Foldable instances for Dual, Sum and Product
      Add Traversable instances for Dual, Sum and Product
      Add Foldable and Traversable instances for First and Last
      Add Applicative, Monad instances to Dual, Sum, Product
      Add MonadFix to Data.Monoid wrappers
      Derive Data for Identity
      Add Data instances to Data.Monoid wrappers
      Add Data (Alt f a) instance
      
      Reviewers: ekmett, dfeuer, hvr, austin
      
      Reviewed By: dfeuer, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D673
      
      GHC Trac Issues: #10107
      4e6bcc2c
    • thomie's avatar
      Pretty-print # on unboxed literals in core · 89458eba
      thomie authored
      Summary:
      Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This
      commit pretty prints the '#'s on unboxed literals in core output.
      
      Test Plan: simplCore/should_compile/T8274
      
      Reviewers: jstolarek, simonpj, austin
      
      Reviewed By: simonpj, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D678
      
      GHC Trac Issues: #8274
      89458eba
    • Tamar Christina's avatar
      Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 · 5200bdeb
      Tamar Christina authored
      Summary:
      On Windows, the default action for things like division by zero and
      segfaults is to pop up a Dr. Watson error reporting dialog if the exception
      is unhandled by the user code.
      
      This is a pain when we are SSHed into a Windows machine, or when we
      want to debug a problem with gdb (gdb will get a first and second chance to
      handle the exception, but if it doesn't the pop-up will show).
      
      veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which
      will catch such exceptions in the entire process and die by
      printing a message and calling `stg_exit(1)`.
      
      Previously this code was handled using SEH (Structured Exception Handlers)
      however each compiler and platform have different ways of dealing with SEH.
      
      `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the
      compiler generate the appropriate SEH handler code for you.
      
      `MinGW` compilers have no such keywords and require you to manually set the
      SEH Handlers, however because SEH is implemented differently in x86 and x64
      the methods to use them in GCC differs.
      
      `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`.
           On startup one would only need to add a new handler there. This has
           a number of issues such as hard to share handlers and it can be exploited.
      
      `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers
           are statically compiled and added to the .pdata section by the compiler.
           Instead of being thread global they can now be Image global since you have to
           specify the `RVA` of the region of code that the handlers govern.
      
      You can on x64 Dynamically allocate SEH handlers, but it seems that (based on
      experimentation and it's very under-documented) that the dynamic calls cannot override
      static SEH handlers in the .pdata section.
      
      Because of this and because GHC no longer needs to support < windows XP, the better
      alternative for handling errors would be using the in XP introduced VEH.
      
      The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API
      is the same for both x86 and x64 (note that the Context object does contain CPU specific
      structures) and the calls are the same cross compilers. Which means this file can be
      simplified quite a bit.
      Using VEH also means we don't have to worry about the dynamic code generated by GHCi.
      
      Test Plan:
      Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows.
      To reproduce the issue on x64:
      1) open ghci
      2) import GHC.Base
      3) run: 1 `divInt` 0
      
      which should lead to ghci crashing an a watson error box displaying.
      
      After applying the patch, run:
      
      make TEST="derefnull divbyzero"
      
      on both x64 and x86 builds of ghc to verify fix.
      
      Reviewers: simonmar, austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D691
      
      GHC Trac Issues: #6079
      5200bdeb
  4. 02 Mar, 2015 18 commits
  5. 27 Feb, 2015 1 commit
  6. 26 Feb, 2015 1 commit
  7. 24 Feb, 2015 4 commits
  8. 23 Feb, 2015 1 commit