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
      b938576d
  2. 03 May, 2017 1 commit
    • David Feuer's avatar
      Improve fixIO · 239418cf
      David Feuer authored
      Use `unsafeDupableInterleaveIO` to avoid `noDuplicate` calls. Switch
      from `takeMVar` to `readMVar` as multiple entry with `takeMVar`
      would lock things up.
      
      Reviewers: austin, hvr, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3494
      239418cf
  3. 29 Apr, 2017 1 commit
  4. 29 Mar, 2017 1 commit
  5. 03 Mar, 2017 1 commit
  6. 26 Feb, 2017 1 commit
  7. 23 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored
      This introduces "freezing," an operation which prevents further
      locations from being appended to a CallStack.  Library authors may want
      to prevent CallStacks from exposing implementation details, as a matter
      of hygiene. For example, in
      
      ```
      head [] = error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      including the call-site of `error` in `head` is not strictly necessary
      as the error message already specifies clearly where the error came
      from.
      
      So we add a function `freezeCallStack` that wraps an existing CallStack,
      preventing further call-sites from being pushed onto it. In other words,
      
      ```
      pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
      ```
      
      Now we can define `head` to not produce a CallStack at all
      
      ```
      head [] =
        let ?callStack = freezeCallStack emptyCallStack
        in error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      ---
      
      1. We add the `freezeCallStack` and `emptyCallStack` and update the
         definition of `CallStack` to support this functionality.
      
      2. We add `errorWithoutStackTrace`, a variant of `error` that does not
         produce a stack trace, using this feature. I think this is a sensible
         wrapper function to provide in case users want it.
      
      3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
         rationale is that base does not export any functions that use CallStacks
         (except for `error` and `undefined`) so there's no way for the stack
         traces (from Implicit CallStacks) to include user-defined functions.
         They'll only contain the call to `error` itself. As base already has a
         good habit of providing useful error messages that name the triggering
         function, the stack trace really just adds noise to the error. (I don't
         have a strong opinion on whether we should include this third commit,
         but the change was very mechanical so I thought I'd include it anyway in
         case there's interest)
      
      4. Updates tests in `array` and `stm` submodules
      
      Test Plan: ./validate, new test is T11049
      
      Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1628
      
      GHC Trac Issues: #11049
      380b25ea
  8. 19 May, 2015 1 commit
  9. 09 Apr, 2015 1 commit
    • rwbarton's avatar
      Import rand using capi · f536d896
      rwbarton authored
      Summary: Android has no rand symbol (it's a static inline function there).
      
      Test Plan: ghc-android builds
      
      Reviewers: trofi, austin, hvr
      
      Reviewed By: hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D826
      
      GHC Trac Issues: #10274
      f536d896
  10. 24 Sep, 2014 1 commit
  11. 21 Sep, 2014 1 commit
  12. 28 Jul, 2014 2 commits
  13. 02 Oct, 2013 1 commit
    • Austin Seipp's avatar
      Fix Windows build. · 47dd3c22
      Austin Seipp authored
      
      
      In dfb52c3d the default language was set to Haskell2010 - by default,
      GHC is less strict about the layout rule (controlled by
      -XNonincreasingIndentation), but not when we explicitly set the language
      to H2010. It turns out we relied on this behavior in the Windows build.
      
      Thanks to Reid Barton for pointing this out.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      47dd3c22
  14. 28 Sep, 2013 1 commit
  15. 17 Sep, 2013 2 commits
  16. 15 Feb, 2013 1 commit
  17. 27 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Remove commented types in module export lists · fda30027
      ian@well-typed.com authored
      These comments are rather less useful now that haddock can give docs
      with the same informatino in the module synopsis.
      
      Having to maintain them when making changes to the library is a pain,
      and when people forget about doing so there is nothing that checks that
      the comments are right, so mistakes tend to linger.
      
      Of the comments that my script detected, 78 of 684 were already
      incorrect in one way or another, e.g. missing context:
          Text.Show.showsPrec
          Comment type: Int -> a -> ShowS
          Actual type:  Show a => Int -> a -> ShowS
      wrong context:
          Numeric.readInt
          Comment type: Integral a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
          Actual type:  Num a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
      not following a class change (e.g. Num losing its Eq superclass):
          Text.Read.Lex.readOctP
          Comment type: Num a => ReadP a
          Actual type:  (Eq a, Num a) => ReadP a
      not following the Exceptions change:
          GHC.Conc.childHandler
          Comment type: Exception -> IO ()
          Actual type:  SomeException -> IO ()
      or just always been wrong:
          GHC.Stable.deRefStablePtr
          Comment type: StablePtr a -> a
          Actual type:  StablePtr a -> IO a
      fda30027
  18. 08 Jun, 2012 1 commit
  19. 07 Jun, 2012 2 commits
  20. 18 Nov, 2011 1 commit
  21. 04 Nov, 2011 1 commit
  22. 26 Oct, 2011 1 commit
  23. 18 Jun, 2011 1 commit
  24. 24 May, 2011 1 commit
  25. 14 May, 2011 1 commit
    • batterseapower's avatar
      Big patch to improve Unicode support in GHC. Validated on OS X and Windows, this · dc58b739
      batterseapower authored
      patch series fixes #5061, #1414, #3309, #3308, #3307, #4006 and #4855.
      
      The major changes are:
      
       1) Make Foreign.C.String.*CString use the locale encoding
      
          This change follows the FFI specification in Haskell 98, which
          has never actually been implemented before.
      
          The functions exported from Foreign.C.String are partially-applied
          versions of those from GHC.Foreign, which allows the user to supply
          their own TextEncoding.
      
          We also introduce foreignEncoding as the name of the text encoding
          that follows the FFI appendix in that it transliterates encoding
          errors.
      
       2) I also changed the code so that mkTextEncoding always tries the
          native-Haskell decoders in preference to those from iconv, even on
          non-Windows. The motivation here is simply that it is better for
          compatibility if we do this, and those are the ones you get for
          the utf* and latin1* predefined TextEncodings anyway.
      
       3) Implement surrogate-byte error handling mode for TextEncoding
      
          This implements PEP383-like behaviour so that we are able to
          roundtrip byte strings through Strings without loss of information.
      
          The withFilePath function now uses this encoding to get to/from CStrings,
          so any code that uses that will get the right PEP383 behaviour automatically.
      
       4) Implement three other coding failure modes: ignore, throw error, transliterate
      
          These mimic the behaviour of the GNU Iconv extensions.
      dc58b739
  26. 28 Jan, 2011 1 commit
  27. 25 Nov, 2010 1 commit
    • Simon Marlow's avatar
      Encode immediately in hPutStr and hPutChar · 62c11c91
      Simon Marlow authored
      This means that decoding errors will be detected accurately, and can
      be caught and handled.  Overall the implementation is simpler this way
      too.
      
      It does impose a performance hit on small hPutStrs, although larger
      hPutStrs seem to be unaffected.  To compensate somewhat, I optimised
      hPutStrLn.
      62c11c91
  28. 16 Nov, 2010 1 commit
  29. 14 Jul, 2010 1 commit
  30. 11 Jul, 2010 1 commit
  31. 29 Jun, 2010 1 commit
  32. 20 May, 2010 1 commit
  33. 20 Jan, 2010 1 commit
  34. 09 Oct, 2009 1 commit
  35. 13 Sep, 2009 1 commit
    • judah's avatar
      On Windows, use the console code page for text file encoding/decoding. · b63b596e
      judah authored
      We keep all of the code page tables in the module
      GHC.IO.Encoding.CodePage.Table.  That file was generated automatically
      by running codepages/MakeTable.hs; more details are in the comments at the
      start of that script.
      
      Storing the lookup tables adds about 40KB to each statically linked executable;
      this only increases the size of a "hello world" program by about 7%.
      
      Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since
      including those codepages would increase the table size to 400KB.  It will be
      straightforward to implement them once the work on library DLLs is finished.
      b63b596e
  36. 09 Aug, 2009 1 commit
    • Ian Lynagh's avatar
      Apply proposal #3393 · 37444277
      Ian Lynagh authored
      Add openTempFileWithDefaultPermissions and
      openBinaryTempFileWithDefaultPermissions.
      37444277
  37. 15 Jul, 2009 1 commit