1. 02 Nov, 2017 1 commit
    • David Feuer's avatar
      Add custom exception for fixIO · b938576d
      David Feuer authored
      Traditionally, `fixIO f` throws `BlockedIndefinitelyOnMVar` if
      `f` is strict. This is not particularly friendly, since the
      `MVar` in question is just part of the way `fixIO` happens to be
      implemented. Instead, throw a new `FixIOException` with a better
      explanation of the problem.
      Reviewers: austin, hvr, bgamari
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #14356
      Differential Revision: https://phabricator.haskell.org/D4113
  2. 04 May, 2017 1 commit
    • Takenobu Tani's avatar
      Fix comment for compact region · 4fcaf8e9
      Takenobu Tani authored
      There were old module names:
       * Data.Compact -> GHC.Compact
       * Data.Compact.Internal -> GHC.Compact
      This commit is for ghc-8.2 branch.
      Test Plan: build
      Reviewers: austin, bgamari, hvr, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3522
  3. 10 Jan, 2017 1 commit
  4. 20 Dec, 2016 1 commit
  5. 07 Dec, 2016 1 commit
    • Simon Marlow's avatar
      Overhaul of Compact Regions (#12455) · 7036fde9
      Simon Marlow authored
      This commit makes various improvements and addresses some issues with
      Compact Regions (aka Compact Normal Forms).
      This was the most important thing I wanted to fix.  Compaction
      previously prevented GC from running until it was complete, which
      would be a problem in a multicore setting.  Now, we compact using a
      hand-written Cmm routine that can be interrupted at any point.  When a
      GC is triggered during a sharing-enabled compaction, the GC has to
      traverse and update the hash table, so this hash table is now stored
      in the StgCompactNFData object.
      Previously, compaction consisted of a deepseq using the NFData class,
      followed by a traversal in C code to copy the data.  This is now done
      in a single pass with hand-written Cmm (see rts/Compact.cmm). We no
      longer use the NFData instances, instead the Cmm routine evaluates
      components directly as it compacts.
      The new compaction is about 50% faster than the old one with no
      sharing, and a little faster on average with sharing (the cost of the
      hash table dominates when we're doing sharing).
      Static objects that don't (transitively) refer to any CAFs don't need
      to be copied into the compact region.  In particular this means we
      often avoid copying Char values and small Int values, because these
      are static closures in the runtime.
      Each Compact# object can support a single compactAdd# operation at any
      given time, so the Data.Compact library now enforces mutual exclusion
      using an MVar stored in the Compact object.
      We now get exceptions rather than killing everything with a barf()
      when we encounter an object that cannot be compacted (a function, or a
      mutable object).  We now also detect pinned objects, which can't be
      compacted either.
      The Data.Compact API has been refactored and cleaned up.  A new
      compactSize operation returns the size (in bytes) of the compact
      Most of the documentation is in the Haddock docs for the compact
      library, which I've expanded and improved here.
      Various comments in the code have been improved, especially the main
      Note [Compact Normal Forms] in rts/sm/CNF.c.
      I've added a few tests, and expanded a few of the tests that were
      there.  We now also run the tests with GHCi, and in a new test way
      that enables sanity checking (+RTS -DS).
      There's a benchmark in libraries/compact/tests/compact_bench.hs for
      measuring compaction speed and comparing sharing vs. no sharing.
      The field totalDataW in StgCompactNFData was unnecessary.
      Test Plan:
      * new unit tests
      * validate
      * tested manually that we can compact Data.Aeson data
      Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd
      Subscribers: thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D2751
      GHC Trac Issues: #12455
  6. 06 Jun, 2016 1 commit
    • seraphime's avatar
      Add @since annotations to base instances · a90085bd
      seraphime authored
      Add @since annotations to instances in `base`.
      Test Plan:
       * ./validate  # some commets shouldn't break the build
       * review the annotations for absurdities.
      Reviewers: ekmett, goldfire, RyanGlScott, austin, hvr, bgamari
      Reviewed By: RyanGlScott, hvr, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2277
      GHC Trac Issues: #11767
  7. 13 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Add -prof stack trace to assert · 6cb860a9
      Simon Marlow authored
      So that assertion failures have full call stack information attached
      when using `ghc -fexternal-interpreter -prof`.  Here's one I just
      collected by inserting a dummy assert in Happy:
      *** Exception: Assertion failed
      CallStack (from ImplicitParams):
        assert, called at ./First.lhs:37:11 in main:First
      CallStack (from -prof):
        First.mkFirst (First.lhs:37:11-27)
        First.mkFirst (First.lhs:37:11-93)
        Main.main2.runParserGen.first (Main.lhs:107:48-56)
        Main.main2.runParserGen.first (Main.lhs:107:27-57)
        Main.main2.runParserGen (Main.lhs:(96,9)-(276,9))
        Main.main2.runParserGen (Main.lhs:(90,9)-(276,10))
        Main.main2.runParserGen (Main.lhs:(86,9)-(276,10))
        Main.main2.runParserGen (Main.lhs:(85,9)-(276,10))
        Main.main2 (Main.lhs:74:20-43)
        Main.main2 (Main.lhs:(64,9)-(78,61))
        Main.main (Main.lhs:57:9-18)
      Test Plan: validate
      Reviewers: erikd, hvr, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1765
      GHC Trac Issues: #11047
  8. 12 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      Test Plan: validate
  9. 23 Sep, 2015 1 commit
  10. 02 Sep, 2015 1 commit
    • Eric Seidel's avatar
      Use IP based CallStack in error and undefined · 6740d70d
      Eric Seidel authored
      This patch modifies `error`, `undefined`, and `assertError` to use
      implicit call-stacks to provide better error messages to users.
      There are a few knock-on effects:
      - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
        types for `error` and `undefined`.
      - `TysPrim.tyVarList` has been replaced with a new function
        `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
        subtle bugs when you need tyvars of different kinds. The naive
        tv1 = head $ tyVarList kind1
        tv2 = head $ tyVarList kind2
        would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
        would be applied incorrectly, treating `tv1` and `tv2` as the same
        tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
        and producing a single tyvar of each kind.
      - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
      - The type `GHC.Exception.ErrorCall` has a new constructor
        `ErrorCallWithLocation` that takes two `String`s instead of one, the
        2nd one being arbitrary metadata about the error (but usually the
        call-stack). A bi-directional pattern synonym `ErrorCall` continues to
        provide the old API.
      Updates Cabal, array, and haddock submodules.
      Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
      liyang, bgamari, thomie
      Differential Revision: https://phabricator.haskell.org/D861
      GHC Trac Issues: #5273
  11. 05 Aug, 2015 1 commit
  12. 14 Apr, 2015 1 commit
  13. 07 Mar, 2015 1 commit
  14. 26 Feb, 2015 1 commit
  15. 23 Feb, 2015 1 commit
  16. 17 Feb, 2015 1 commit
  17. 16 Dec, 2014 1 commit
  18. 24 Nov, 2014 1 commit
  19. 12 Nov, 2014 1 commit
  20. 16 Sep, 2014 1 commit
  21. 27 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Replace DeriveDataTypeable by AutoDeriveTypeable · 6ed54303
      Herbert Valerio Riedel authored
      This is a first step towards addressing #9111
      This results in the following additional Typeable (exported) instances
      being generated (list was compiled by diff'ing hoogle txt output):
        instance Typeable CFile
        instance Typeable 'CFile
        instance Typeable CFpos
        instance Typeable 'CFpos
        instance Typeable CJmpBuf
        instance Typeable 'CJmpBuf
        instance Typeable ChItem
        instance Typeable QSem
        instance Typeable ID
        instance Typeable 'ID
        instance Typeable CONST
        instance Typeable Qi
        instance Typeable Qr
        instance Typeable Mp
        instance Typeable ConstrRep
        instance Typeable Fixity
        instance Typeable 'Prefix
        instance Typeable 'Infix
        instance Typeable Constr
        instance Typeable DataType
        instance Typeable DataRep
        instance Typeable Data
        instance Typeable HasResolution
        instance Typeable IsList
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
  22. 04 May, 2014 1 commit
  23. 02 May, 2014 1 commit
    • Simon Marlow's avatar
      Per-thread allocation counters and limits · b0534f78
      Simon Marlow authored
      This tracks the amount of memory allocation by each thread in a
      counter stored in the TSO.  Optionally, when the counter drops below
      zero (it counts down), the thread can be sent an asynchronous
      exception: AllocationLimitExceeded.  When this happens, given a small
      additional limit so that it can handle the exception.  See
      documentation in GHC.Conc for more details.
      Allocation limits are similar to timeouts, but
        - timeouts use real time, not CPU time.  Allocation limits do not
          count anything while the thread is blocked or in foreign code.
        - timeouts don't re-trigger if the thread catches the exception,
          allocation limits do.
        - timeouts can catch non-allocating loops, if you use
          -fno-omit-yields.  This doesn't work for allocation limits.
      I couldn't measure any impact on benchmarks with these changes, even
      for nofib/smp.
  24. 21 Feb, 2014 1 commit
  25. 21 Sep, 2013 1 commit
    • Herbert Valerio Riedel's avatar
      Add Haddock `/Since:` comments to new symbols · 77f32dad
      Herbert Valerio Riedel authored
      These annotations were added in such a way, that the line
      represents the last paragraph of the Haddock comment.
      Maybe Haddock will have support for this meta-syntax at some point, and
      be able to inherited the since-version property to the children of an
      annotated symbol and display the since-version property in the rendered
      documentation only in cases when it's not visually obvious (for
      instance, when re-exporting documentation strings).
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
  26. 18 Sep, 2013 2 commits
  27. 10 Dec, 2012 1 commit
    • Simon Marlow's avatar
      Make a class for asynchronous exceptions in the exception hierarchy · 756a970e
      Simon Marlow authored
      Right now, we only have
      data AsyncException
        = StackOverflow
        | HeapOverflow
        | ThreadKilled
        | ...
      so it is not possible to add another async exception.  For instance,
      the Timeout exception in System.Timeout should really be an async
      This patch adds a superclass for all async exceptions:
      data SomeAsyncException = forall e . Exception e => SomeAsyncException e
        deriving Typeable
      and makes the existing AsyncException and Timeout children of
      SomeAsyncException in the hierarchy.
  28. 17 Nov, 2012 1 commit
  29. 26 Oct, 2011 1 commit
  30. 19 Oct, 2011 1 commit
  31. 18 Jun, 2011 1 commit
  32. 28 Jan, 2011 1 commit
  33. 22 Jun, 2010 1 commit
  34. 23 Apr, 2010 1 commit
  35. 12 Mar, 2010 1 commit
  36. 01 Mar, 2010 1 commit
  37. 30 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Address #3310 · a5e2fa98
      Simon Marlow authored
       - Rename BlockedOnDeadMVar   -> BlockedIndefinitelyOnMVar
       - Rename BlockedIndefinitely -> BlockedIndefinitelyOnSTM
       - instance Show BlockedIndefinitelyOnMVar is now
           "blocked indefinitely in an MVar operation"
       - instance Show BlockedIndefinitelyOnSTM is now
           "blocked indefinitely in an STM transaction"
      clients using Control.OldException will be unaffected (the new
      exceptions are mapped to the old names).  However, for base4-compat
      we'll need to make a version of catch/try that does a similar
  38. 15 Jul, 2009 1 commit
  39. 12 Jun, 2009 1 commit
    • Simon Marlow's avatar
      Rewrite of the IO library, including Unicode support · 7b067f2d
      Simon Marlow authored
      * Unicode support for Handle I/O:
        ** Automatic encoding and decoding using a per-Handle encoding.
        ** The encoding defaults to the locale encoding (only on Unix 
           so far, perhaps Windows later).
        ** Built-in UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE) codecs.
        ** iconv-based codec for other encodings on Unix
      * Modularity: the low-level IO interface is exposed as a type class
        (GHC.IO.IODevice) so you can build your own low-level IO providers and
        make Handles from them.
      * Newline translation: instead of being Windows-specific wired-in
        magic, the translation from \r\n -> \n and back again is available
        on all platforms and is configurable for reading/writing
      Unicode-aware Handles
      This is a significant restructuring of the Handle implementation with
      the primary goal of supporting Unicode character encodings.
      The only change to the existing behaviour is that by default, text IO
      is done in the prevailing locale encoding of the system (except on
      Windows [1]).  
      Handles created by openBinaryFile use the Latin-1 encoding, as do
      Handles placed in binary mode using hSetBinaryMode.
      We provide a way to change the encoding for an existing Handle:
         GHC.IO.Handle.hSetEncoding :: Handle -> TextEncoding -> IO ()
      and various encodings (from GHC.IO.Encoding):
         utf16, utf16le, utf16be,
         utf32, utf32le, utf32be,
      and a way to lookup other encodings:
         GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding
      (it's system-dependent whether the requested encoding will be
      We may want to export these from somewhere more permanent; that's a
      topic for a future library proposal.
      Thanks to suggestions from Duncan Coutts, it's possible to call
      hSetEncoding even on buffered read Handles, and the right thing
      happens.  So we can read from text streams that include multiple
      encodings, such as an HTTP response or email message, without having
      to turn buffering off (though there is a penalty for switching
      encodings on a buffered Handle, as the IO system has to do some
      re-decoding to figure out where it should start reading from again).
      If there is a decoding error, it is reported when an attempt is made
      to read the offending character from the Handle, as you would expect.
      Performance varies.  For "hGetContents >>= putStr" I found the new
      library was faster on my x86_64 machine, but slower on an x86.  On the
      whole I'd expect things to be a bit slower due to the extra
      decoding/encoding, but probabaly not noticeably.  If performance is
      critical for your app, then you should be using bytestring and text
      [1] Note: locale encoding is not currently implemented on Windows due
      to the built-in Win32 APIs for encoding/decoding not being sufficient
      for our purposes.  Ask me for details.  Offers of help gratefully
      Newline Translation
      In the old IO library, text-mode Handles on Windows had automatic
      translation from \r\n -> \n on input, and the opposite on output.  It
      was implemented using the underlying CRT functions, which meant that
      there were certain odd restrictions, such as read/write text handles
      needing to be unbuffered, and seeking not working at all on text
      In the rewrite, newline translation is now implemented in the upper
      layers, as it needs to be since we have to perform Unicode decoding
      before newline translation.  This means that it is now available on
      all platforms, which can be quite handy for writing portable code.
      For now, I have left the behaviour as it was, namely \r\n -> \n on
      Windows, and no translation on Unix.  However, another reasonable
      default (similar to what Python does) would be to do \r\n -> \n on
      input, and convert to the platform-native representation (either \r\n
      or \n) on output.  This is called universalNewlineMode (below).
      The API is as follows.  (available from GHC.IO.Handle for now, again
      this is something we will probably want to try to get into System.IO
      at some point):
      -- | The representation of a newline in the external file or stream.
      data Newline = LF    -- ^ "\n"
                   | CRLF  -- ^ "\r\n"
                   deriving Eq
      -- | Specifies the translation, if any, of newline characters between
      -- internal Strings and the external file or stream.  Haskell Strings
      -- are assumed to represent newlines with the '\n' character; the
      -- newline mode specifies how to translate '\n' on output, and what to
      -- translate into '\n' on input.
      data NewlineMode 
        = NewlineMode { inputNL :: Newline,
                          -- ^ the representation of newlines on input
                        outputNL :: Newline
                          -- ^ the representation of newlines on output
                   deriving Eq
      -- | The native newline representation for the current platform
      nativeNewline :: Newline
      -- | Map "\r\n" into "\n" on input, and "\n" to the native newline
      -- represetnation on output.  This mode can be used on any platform, and
      -- works with text files using any newline convention.  The downside is
      -- that @readFile a >>= writeFile b@ might yield a different file.
      universalNewlineMode :: NewlineMode
      universalNewlineMode  = NewlineMode { inputNL  = CRLF, 
                                            outputNL = nativeNewline }
      -- | Use the native newline representation on both input and output
      nativeNewlineMode    :: NewlineMode
      nativeNewlineMode     = NewlineMode { inputNL  = nativeNewline, 
                                            outputNL = nativeNewline }
      -- | Do no newline translation at all.
      noNewlineTranslation :: NewlineMode
      noNewlineTranslation  = NewlineMode { inputNL  = LF, outputNL = LF }
      -- | Change the newline translation mode on the Handle.
      hSetNewlineMode :: Handle -> NewlineMode -> IO ()
      IO Devices
      The major change here is that the implementation of the Handle
      operations is separated from the underlying IO device, using type
      classes.  File descriptors are just one IO provider; I have also
      implemented memory-mapped files (good for random-access read/write)
      and a Handle that pipes output to a Chan (useful for testing code that
      writes to a Handle).  New kinds of Handle can be implemented outside
      the base package, for instance someone could write bytestringToHandle.
      A Handle is made using mkFileHandle:
      -- | makes a new 'Handle'
      mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev)
                    => dev -- ^ the underlying IO device, which must support
                           -- 'IODevice', 'BufferedIO' and 'Typeable'
                    -> FilePath
                           -- ^ a string describing the 'Handle', e.g. the file
                           -- path for a file.  Used in error messages.
                    -> IOMode
                           -- ^ The mode in which the 'Handle' is to be used
                    -> Maybe TextEncoding
                           -- ^ text encoding to use, if any
                    -> NewlineMode
                           -- ^ newline translation mode
                    -> IO Handle
      This also means that someone can write a completely new IO
      implementation on Windows based on native Win32 HANDLEs, and
      distribute it as a separate package (I really hope somebody does
      This restructuring isn't as radical as previous designs.  I haven't
      made any attempt to make a separate binary I/O layer, for example
      (although hGetBuf/hPutBuf do bypass the text encoding and newline
      translation).  The main goal here was to get Unicode support in, and
      to allow others to experiment with making new kinds of Handle.  We
      could split up the layers further later.
      API changes and Module structure
      NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still
      present, but are just re-exporting things from other modules now).
      For 6.12 we'll want to bump base to version 5 and add a base4-compat.
      For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated
      I split modules into smaller parts in many places.  For example, we
      now have GHC.IORef, GHC.MVar and GHC.IOArray containing the
      implementations of IORef, MVar and IOArray respectively.  This was
      necessary for untangling dependencies, but it also makes things easier
      to follow.
      The new module structurue for the IO-relatied parts of the base
      package is:
         Implementation of the IO monad; unsafe*; throw/catch
         The IOMode type
         Buffers and operations on them
         The IODevice and RawIO classes.
         The BufferedIO class.
         The FD type, with instances of IODevice, RawIO and BufferedIO.
         IO-related Exceptions
         The TextEncoding type; built-in TextEncodings; mkTextEncoding
         Implementation internals for GHC.IO.Encoding
         The main API for GHC's Handle implementation, provides all the Handle
         operations + mkFileHandle + hSetEncoding.
         Implementation of Handles and operations.
         Parts of the Handle API implemented by file-descriptors: openFile,
         stdin, stdout, stderr, fdToHandle etc.