June 2014 - ghc-tickets

[GHC] #9086: main :: IO Int does different things with runghc and when compiled
by GHC 14 Jul '14

14 Jul '14

#9086: main :: IO Int does different things with runghc and when compiled --------------------------+------------------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.2 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Consider {{{ main :: IO Int main = return 1 }}} This does different things when compiled and when run with `runghc`/`runhaskell` (it prints an extra `1` with the latter). For practical purposes, I think it is beneficial if either of the two ways to run a Haskell program have the same output. Or did somebody intend this to happen? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9196: Higher-rank constraint treated as type instead
by GHC 13 Jul '14

13 Jul '14

#9196: Higher-rank constraint treated as type instead ------------------------------------+------------------------------------- Reporter: goldfire | 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 say {{{ {-# LANGUAGE RankNTypes #-} module Bug where class P z foo :: (forall b. P (a, b)) => a -> a foo x = x }}} I get {{{ Bug.hs:7:9: Couldn't match expected type ‘a -> a’ with actual type ‘P (a, b0)’ Relevant bindings include x :: forall b. P (a, b) (bound at Bug.hs:7:5) foo :: (forall b. P (a, b)) -> a -> a (bound at Bug.hs:7:1) In the expression: x In an equation for ‘foo’: foo x = x }}} I expected my code to be rejected, but not with that error message. It seems that GHC thinks `forall b. P (a, b))` has kind `*`, not kind `Constraint`. Encountered while experimenting with #9195. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9174: Haddock fails with "Module defined in multiple files"
by GHC 13 Jul '14

13 Jul '14

#9174: Haddock fails with "Module defined in multiple files" ----------------------------------+--------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Haddock fails to cooperate with OS X clang CPP: {{{ <no location info>: module ‘pkgid-pkgversion:Main’ is defined in multiple files: dist/build/tmp-#####/Stuff }}} A workaround is to pass `--ghc-options=-optP-P` to `cabal haddock`. This prevents `cabal-install` from being boostrapped, unless `--no-doc` is specified. The original Haddock ticket and the corresponding Cabal issue were both closed as invalid, but there appears to be no GHC ticket to track the underlying cause. http://trac.haskell.org/haddock/ticket/284 https://github.com/haskell/cabal/issues/1740 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv)
by GHC 09 Jul '14

09 Jul '14

#9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------------------+------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- A patch in GHC-7.7 modified the "thread stop status" encoding, so the current ghc-events (version 0.4.2.0 from 2012) produces wrong stop reasons when reading an eventlog written by GHC-7.8.2. The GHC patch is http://git.haskell.org/ghc.git/commit/70e20631742e516c6a11c3c112fbd5b4a08c1… The MVarRead block reason was added in the middle, shifting all following block reason codes one up. The error can be observed when a thread blocks on a black hole during a program run. Attached is a small test program which produces this situation, and two event logs for the same program run with the same arguments and RTS parameters. The program's two threads evaluate the same data, the parent thread typically blocks on a blackhole created by a forked child thread. Note the sequence around user event "child": The log written by GHC-7.6.3 correctly shows blocking on a black hole, while the log written by GHC-7.8.2 claims the main thread blocks "on I/O read". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9175: Bad interaction between Pattern Synonyms and Text
by GHC 03 Jul '14

03 Jul '14

#9175: Bad interaction between Pattern Synonyms and Text -----------------------------------+--------------------------------------- Reporter: emertens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Compiling this file causes the impossible to happen. It is necessary to enable optimizations. The bug did not occur if the Text parameter was replaced with ByteString or String. {{{ {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE OverloadedStrings #-} module Bug where {- - Must compile with optimizations - - text-1.1.1.3 - ghc-7.8.2 - Both Darwin and Linux platforms - -} import Data.Text(Text) data T = C Text Bool f :: a -> b f _ = undefined {-# NOINLINE f #-} -- important pattern P1 a = C "sh" a -- at least two characters pattern P2 = C "x" True -- this pattern has to come last g :: Text -> T g x = case x of "" -> f (P1 undefined) -- this has to be a pattern synonym }}} {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): StgCmmEnv: variable not found lvl_s2Jr{v} [lid] local binds for: main:Bug.f{v rBS} [gid] main:Bug.rewriteRule{v rBV} [gid] main:Bug.$mP2{v r17q} [gid] main:Bug.$WP2{v r17A} [gid] main:Bug.$mP1{v r17E} [gid] main:Bug.$WP1{v r17R} [gid] main:Bug.$WP3{v r3bq} [gid] main:Bug.$WP4{v r3ua} [gid] main:Bug.$WP5{v r3ub} [gid] main:Bug.$WP2_dt{v r3uc} [gid] main:Bug.$WP6{v r3ud} [gid] main:Bug.$WP7{v r3ue} [gid] main:Bug.$WP8{v r3uf} [gid] main:Bug.$w$mP1{v r3ug} [gid] main:Bug.$w$mP2{v r3uh} [gid] main:Bug.$mP3{v r3ui} [gid] main:Bug.$mP4{v r3uj} [gid] main:Bug.$mP5{v r3uk} [gid] main:Bug.$wrewriteRule{v r3ul} [gid] main:Bug.rewriteRule1{v r3um} [gid] main:Bug.rewriteRule2{v r3un} [gid] main:Bug.rewriteRule3{v r3uo} [gid] main:Bug.rewriteRule4{v r3up} [gid] main:Bug.rewriteRule5{v r3uq} [gid] lvl{v r3ur} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9023: Error when using empty record update on binary pattern synonym
by GHC 03 Jul '14

03 Jul '14

#9023: Error when using empty record update on binary pattern synonym --------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+--------------------------------- Using an empty record update with patterns works here {{{ pattern Singleton a = [a] isSingleton :: [a] -> Bool isSingleton Singleton{} = True isSingleton _ = False }}} but fails in the follow example (there may exist a more minimal example) {{{ pattern P a b = Just (a, b) foo P{} = True }}} which outputs (GHC 7.8.2) {{{ $ ghci -ignore-dot-ghci tmp.g2WZtTUkhJ.hs GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( tmp.g2WZtTUkhJ.hs, interpreted ) Var/Type length mismatch: [t{tv aIW} [sk]] [] Ok, modules loaded: Main. *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9018: GHC suppresses too much kind information
by GHC 03 Jul '14

03 Jul '14

#9018: GHC suppresses too much kind information ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- GHC tends to hide important kind polymorphism in error messages and in GHCi. (I came across this when looking at #9017.) For example, try this: {{{ bash$ cat Test.hs {-# LANGUAGE PolyKinds #-} module Test where foo :: m a foo = foo bash$ ghci Test.hs ghci> :t foo foo :: m a ghci> :i foo foo :: m a bash$ ghci Test.hs -XPolyKinds ghci> :t foo foo :: m a ghci> :i foo goo :: m a bash$ ghci Test.hs -fprint-explicit-foralls -fprint-explicit-kinds ghci> :t foo foo :: foo :: forall (m :: * -> *) d. m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d bash$ ghci Test.hs -XPolyKinds -fprint-explicit-foralls -fprint-explicit- kinds ghci> :t foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d ghci> :i foo foo :: forall (k :: BOX) (m :: k -> *) (d :: k). m d }}} Pretty confusing eh? * Without `-fprint-explicit-foralls -fprint-explicit-kinds` you don't see the kinds on the types at all. * Without `-XPolyKinds` in GHCi, when you say `:t foo` you are asking for the type of the expression `foo` (it could be an arbitrary expression). So `foo` is instantiated and then re-generalised; but without `-XPolyKinds` we don't get a poly-kinded type. Hence the difference in what is printed by `:type` and `:info`. Here's a proposal: even without `-fprint-explicit-foralls`, we should print any foralls that bind a type variable whose kind includes a kind variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module
by GHC 03 Jul '14

03 Jul '14

#9071: Panic with -XDeriveFunctor when deriving from a non-Functor in a separate module -----------------------------------+--------------------------------------- Reporter: bens | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- == Mu in the same file == ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where newtype Mu f = Mu (f (Mu f)) newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 1] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:7:37: No instance for (Functor Mu) arising from the first field of ‘F’ (type ‘Mu (K a)’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Functor F) }}} == Mu in a separate file == ''src/Mu.hs'' {{{ module Mu where newtype Mu f = Mu (f (Mu f)) }}} ''src/Main.hs'' {{{ {-# LANGUAGE DeriveFunctor #-} module Main where import Mu newtype K a b = K a newtype F a = F (Mu (K a)) deriving Functor main :: IO () main = return () }}} ---- {{{ $ cabal build Building panic-0.1.0.0... Preprocessing executable 'panic' for panic-0.1.0.0... [1 of 2] Compiling Mu ( src/Mu.hs, dist/build/panic/panic- tmp/Mu.o ) [2 of 2] Compiling Main ( src/Main.hs, dist/build/panic/panic- tmp/Main.o ) src/Main.hs:8:37:ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Prelude.(!!): index too large Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object)
by GHC 02 Jul '14

02 Jul '14

#9012: HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object) ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- This happens in a clean sandbox: {{{ % cabal install -j --enable-library-coverage logict Resolving dependencies... Notice: installing into a sandbox located at /home/feuerbach/tmp/sandboxes/smallcheck-bug/.cabal-sandbox Configuring mtl-2.1.3.1... Building mtl-2.1.3.1... Installed mtl-2.1.3.1 Configuring logict-0.6.0.2... Building logict-0.6.0.2... Failed to install logict-0.6.0.2 Last 10 lines of the build log ( /home/feuerbach/tmp/sandboxes/smallcheck- bug/.cabal-sandbox/logs/logict-0.6.0.2.log ): Configuring logict-0.6.0.2... Building logict-0.6.0.2... Preprocessing library logict-0.6.0.2... [1 of 2] Compiling Control.Monad.Logic.Class ( Control/Monad/Logic/Class.hs, dist/dist-sandbox- cdfcc6f0/build/Control/Monad/Logic/Class.o ) [2 of 2] Compiling Control.Monad.Logic ( Control/Monad/Logic.hs, dist /dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.o ) /usr/bin/ld: dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.dyn_o: relocation R_386_GOTOFF against undefined symbol `_hpc_tickboxes_mtlzm2zi1zi3zi1_ControlziMonadziReaderziClass_hpc' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: logict-0.6.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9168: reading/writing blocking FDs over FD_SETSIZE is broken
by GHC 02 Jul '14

02 Jul '14

#9168: reading/writing blocking FDs over FD_SETSIZE is broken ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC.IO.FD` when reading from or writing to a blocking FD we first check (using our C function `fdReady`) whether the underlying fd is ready for read/write, in an attempt to avoid blocking the current OS thread. On POSIX this check is done using select, with no test for whether the fd exceeds `FD_SETSIZE`, causing a write out of bounds and various bad consequences. Also, while `readRawBufferPtr` checks the error status of `fdReady`, `readRawBufferPtrNoBlock`, `writeRawBufferPtr`, `writeRawBufferPtrNoBlock` do not, making this issue harder to diagnose. I suggest that `fdReady` use `poll(2)` where available. I can prepare a set of patches if needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6