December 2014 - ghc-tickets

[GHC] #9664: Add identity functor to base
by GHC 22 Feb '15

22 Feb '15

#9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet. This was already [https://groups.google.com/forum/#!msg/haskell-core- libraries/_nReDCbROew/Mdmf0zIloysJ proposed to the CLC back in early 2013], and already missed inclusion in GHC 7.8 However, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9631: Comment in GHC.Base about GHC.Prim does not appear to be correct
by GHC 22 Feb '15

22 Feb '15

#9631: Comment in GHC.Base about GHC.Prim does not appear to be correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The comment reads {{{ GHC.Prim Has no implementation. It defines built-in things, and by importing it you bring them into scope. The source file is GHC.Prim.hi-boot, which is just copied to make GHC.Prim.hi }}} It does not appear that any files by these names exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8362: Filesystem related tests failed on solaris (SmartOS)
by GHC 22 Feb '15

22 Feb '15

#8362: Filesystem related tests failed on solaris (SmartOS) --------------------------+------------------------------------------------ Reporter: leroux | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 7.6.3 libraries (other) | Operating System: Solaris Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Getting filesystem (files/permissions) related test faiures on SmartOS (32bit). {{{ $ uname -a SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris }}} Unexpected failures: `TEST="openFile003 getPermissions001 processGroup002 user001 posix005"` The testsuite output is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9388: Narrow the scope of the notorious "state hack"
by GHC 22 Feb '15

22 Feb '15

#9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The "state hack" has caused any number of bug reports (just search for that string), the most recent of which is #9349. Here's an idea to make it less pervasive: (roughly) use the state hack only for top-level functions definitions. The idea is that for nested lambdas the context should give the one-shot- ness, now that we are equipped with cardinality analysis. For example, consider the call {{{ replicatM_ 1000 (\(s :: RealWorld#) -> blah) }}} The lambda is 1000-shot, not one-shot, notwithstanding the type of the binder. Moreover `replicateM_`'s strictness/cardinality signature will say just that, and GHC already knows how to propagate that information onto the `\s`. But for top level functions like {{{ pr :: String -> IO () pr x = putStrLn (reverse x) }}} we get Core {{{ pr = \x. let y = reverse x in \ (s :: State# RealWorld). putStrLn y s }}} and, since we can't see all the callers of `pr`, we don't know if work is lost by pushing the `reverse` call inside, to get {{{ pr = \x. (s :: State# RealWorld). putStrLn (reverse x) s }}} which is much more efficient. Indeed, this might not be so good if the calls looked like {{{ ... replicateM_ 1000 (pr "foo")... }}} because then "foo" will be reversed 1000 times. But arguably that's what the programmer expects anyway, looking at the code; and the efficiency hit from not eta-expanding all functions like `pr` (which are very very common) is significant. The point is the that the only ones that need hacking are the top-level guys, and maybe even the top-level ''exported'' guys. I have not fully thought this through, let alone tried it out, but I wanted to capture the thought. It would need some careful performance testing. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8280: Deriving Show for Word#
by GHC 21 Feb '15

21 Feb '15

#8280: Deriving Show for Word# ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ {-# LANGUAGE MagicHash #-} import GHC.Prim data A = A Word# deriving Show }}} This works in 7.6.3, but 7.7 gives {{{ Can't find interface-file declaration for data constructor GHC.Types.W# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} The same file works if Word# is replaced by Int#. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9054: runghc-<version> does not call ghc of the same version
by GHC 18 Feb '15

18 Feb '15

#9054: runghc-<version> does not call ghc of the same version ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I ran runghc-7.6.3, it actually executed "/usr/local/bin/ghc" which points to ghc-7.8.2. The offending line is inside the runghc-<version> script: {{{ exec "$executablename" -f "$bindir/ghc" ${1+"$@"} }}} Which should be: {{{ exec "$executablename" -f "$bindir/ghc-<version>" ${1+"$@"} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9402: Vestigial external core code in genprimops
by GHC 18 Feb '15

18 Feb '15

#9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It looks like `gen_ext_core_source` in `utils/genprimopcode/Main.hs` is no longer needed. I'm not quite confident enough here to make the change myself, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9606: Improve outdated ghc-pkg cache warning
by GHC 18 Feb '15

18 Feb '15

#9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Sometimes you get this: {{{ WARNING: cache is out of date: /home/user/.ghc/x86_64-linux-7.8.3/package.conf.d/package.cache. Use 'ghc-pkg recache' to fix }}} The warning is correct but a bit confusing, because running `ghc-pkg recache` does nothing here: It will by default update your global package DB, and the DB the warning is about will still be out of date. This seems to have frustrated others as well: https://gist.github.com/mcandre/5789498 I suggest we make the message more clear: `You might have to pass --user to update this cache file`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9094: remove RAW_CPP
by GHC 18 Feb '15

18 Feb '15

#9094: remove RAW_CPP ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 8683 | Blocking: Related Tickets: #8683 | ------------------------------------+------------------------------------- once the CPP settings ticket is merged #8683 one cleanup task is to remove the RAW_CPP bits from the ghc build system because they're not longer needed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9395: Debug.Trace should not use %s for format string
by GHC 18 Feb '15

18 Feb '15

#9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The current implementation of traceIO in Debug.Trace is as follows: {{{ traceIO :: String -> IO () traceIO msg = do withCString "%s\n" $ \cfmt -> withCString msg $ \cmsg -> debugBelch cfmt cmsg }}} This is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null. Probably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be: {{{ main = trace "\0foo" (return ()) }}} which should have non-empty output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6