1. 17 Jun, 2018 1 commit
  2. 18 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Add CBool to Foreign.C.Types · 0d769d5b
      Ryan Scott authored
      This adds a `CBool` type wrapping C99's `bool`, i.e., an `unsigned
      Fixes #13136.
      Test Plan: ./validate on Tier-1 platforms
      Reviewers: austin, hvr, simonmar, bgamari
      Reviewed By: simonmar, bgamari
      Subscribers: thomie, erikd
      Differential Revision: https://phabricator.haskell.org/D2982
      GHC Trac Issues: #13136
  3. 02 Oct, 2016 1 commit
  4. 10 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Add platform warning to Foreign.C.Types · 710f21cc
      Tamar Christina authored
      The generated documentation for thhe Foreign.C.Types
      module is generated based on the platform which ran Haddock.
      This is generating incorrect types for e.g. Windows.
      Add a disclaimer to the top of the page to ask people to
      keep this in mind.
      Test Plan: make documentation and inspect Haddock
      Reviewers: erikd, austin, hvr, bgamari
      Reviewed By: erikd
      Subscribers: RyanGlScott, #ghc_windows_task_force, thomie
      Differential Revision: https://phabricator.haskell.org/D2523
      GHC Trac Issues: #12586
  5. 06 Jun, 2016 1 commit
  6. 01 May, 2016 1 commit
    • Ryan Scott's avatar
      Export constructors for IntPtr and WordPtr · a28611b1
      Ryan Scott authored
      This finishes what #5529 started by exporting the constructors for
      `IntPtr` and `WordPtr` from `Foreign.Ptr`, allowing them to be used in
      `foreign` declarations.
      Fixes #11983.
      Test Plan: `make TEST=T11983`
      Reviewers: simonpj, hvr, bgamari, austin
      Reviewed By: simonpj
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D2142
      GHC Trac Issues: #11983
  7. 16 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Start using `-W` instead of `-f(no-)warn` in some places · 437ebdda
      Herbert Valerio Riedel authored
      This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases
      introduced via 2206fa8c / #11218, in cases which are guaranteed
      to be invoked with recent enough GHC (i.e. the stage1+ GHC).
      After this commit, mostly the compiler and the testsuite remain using
      `-f(wo-)warn...` because the compiler needs to be bootstrappable with
      older GHCs, while for the testsuite it's convenient to be able to quickly
      compare the behavior to older GHCs (which may not support the new flags yet).
      The compiler-part can be updated to use the new flags once GHC 8.3 development
      Reviewed By: quchen
      Differential Revision: https://phabricator.haskell.org/D1637
  8. 18 Mar, 2015 1 commit
  9. 07 Mar, 2015 1 commit
  10. 16 Dec, 2014 1 commit
  11. 21 Nov, 2014 1 commit
  12. 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>
  13. 30 Jan, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Derive `FiniteBits` for integral newtype wrappers · 276c4621
      Herbert Valerio Riedel authored
      When `FiniteBits` was introduced in cddc9024e67a6d4c01bb190839d0134af8c907e0
      only the standard Haskell 2010 finite-size integral types were given a
      `FiniteBits` instance, however, since also a DEPRECATION warning was put
      in place (as per 701d9ed4b2bec5922709a91bfb625881d7dd47f0) for `bitSize`
      which might point people to to `FiniteBits`, it seems sensible to derive
      `FiniteBits` for all integral newtype wrappers as well.
      N.B.: This makes `Integer` the only type in `base` with a `Bits`
            instance but no `FiniteBits` instance.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
  14. 22 Sep, 2013 1 commit
  15. 17 Sep, 2013 3 commits
  16. 06 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Re-jig SOURCE imports · 8d87b5bf
      Simon Peyton Jones authored
      * Do not have have an hs-boot file for Data.Typeable
      * Instead make all the loops go through
           GHC.Err (just a couple of magic functions)
           GHC.Exception (some non-exceptional functions)
      The main idea is
        a) don't involve classes in the hs-boot world
        b) loop through error cases where performance doesn't matter
        c) be careful not to SOURCE import things that are bottom,
           unless MkCore knows about them in eRROR_IDS, so that we
           see their strictness
  17. 15 Feb, 2013 1 commit
  18. 17 Nov, 2012 3 commits
  19. 26 Oct, 2011 1 commit
  20. 20 Oct, 2011 1 commit
  21. 25 Aug, 2011 1 commit
  22. 11 Jul, 2011 1 commit
    • Simon Marlow's avatar
      Typeable overhaul (see #5275) · e0b63e02
      Simon Marlow authored
      Instances of Typeable used to call mkTyCon:
        mkTyCon :: String -> TyCon
      which internally kept a table mapping Strings to Ints, so that each
      TyCon could be given a unique Int for fast comparison.  This meant the
      String has to be unique across all types in the program.  However,
      derived instances of typeable used the qualified original
      name (e.g. "GHC.Types.Int") which is not necessarily unique, is
      non-portable, and exposes implementation details.
      The String passed to mkTyCon is returned by
        tyConString :: TyCon -> String
      which let the user get at this non-portable representation (also the
      Show instance returns this String).
      Now we store three Strings in TyCon.  The internal representation is
      data TyCon = TyCon {
         tyConHash    :: {-# UNPACK #-} !Fingerprint,
         tyConPackage :: String,
         tyConModule  :: String,
         tyConName    :: String
      (internal representations are now provided by Data.Typeable.Internal)
      The fields of TyCon are not exposed via the public API.  Together the
      three fields tyConPackage, tyConModule and tyConName uniquely identify
      a TyCon, and the Fingerprint is a hash of the concatenation of these
      three Strings (so no more internal cache to map strings to unique
      Ids). tyConString now returns the value of tyConName only, so is
      therefore portable (but the String returned does not uniquely
      identify the TyCon).
      I've measured the performance impact of this change, and performance
      seems to be uniformly better.  This should improve things for SYB in
      particular.  Also, the size of the code generated for deriving
      Typeable is less than half as much as before.
      == API changes ==
      === mkTyCon is DEPRECATED ==
      mkTyCon is used by some hand-written instances of Typeable.  It still
      works as before, but is deprecated in favour of...
      === Add mkTyCon3 ===
        mkTyCon3 :: String -> String -> String -> TyCon
      mkTyCon3 takes the package, module, and name of the TyCon respectively.
      Most users can just derive Typeable, there's no need to use mkTyCon3.
      In due course we can rename mkTyCon3 back to mkTyCon.
      === typeRepKey changed ===
      Previously we had
        typeRepKey :: TypeRep -> IO Int
      but since we don't assign unique Ints to TypeReps any more, this is
      difficult to implement.  Instead we provide an abstract key type which
      is an instance of Eq and Ord, and internally is implemented by the
        data TypeRepKey -- abstract, instance of Eq, Ord
        typeRepKey :: TypeRep -> IO TypeRepKey
      typeRepKey is still in the IO monad, because the Ord instance is
  23. 18 Jun, 2011 1 commit
  24. 11 Jun, 2011 2 commits
  25. 24 Apr, 2011 1 commit
  26. 28 Jan, 2011 1 commit
  27. 25 Oct, 2010 1 commit
  28. 01 Jul, 2010 1 commit
  29. 05 Jul, 2009 1 commit
  30. 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.
  31. 14 Jan, 2009 1 commit
  32. 05 Aug, 2008 1 commit
  33. 16 Jun, 2008 1 commit
  34. 05 Mar, 2008 1 commit
  35. 05 Dec, 2007 1 commit