October 2013 - ghc-tickets

[GHC] #8450: can't match type Bool with (), but shouldn't have to
by GHC 22 Nov '13

22 Nov '13

#8450: can't match type Bool with (), but shouldn't have to ------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- The following (definitely type-incorrect) file: {{{ {-# LANGUAGE ScopedTypeVariables #-} runEffect :: Either Bool r -> r runEffect = undefined run :: forall a. a run = runEffect $ (undefined :: Either a ()) }}} produces the following error: {{{ test.hs:7:7: Couldn't match type `Bool' with `()' Expected type: a Actual type: () In the expression: runEffect $ (undefined :: Either a ()) In an equation for `run': run = runEffect $ (undefined :: Either a ()) }}} This is strange because one of the two types it claims it can't unify (Bool) doesn't appear in either the expected or actual type. Note that removing the ($) gets a different error message that makes it a bit more clear what's going on: {{{ test.hs:7:18: Couldn't match type `Bool' with `()' Expected type: Either Bool a Actual type: Either a () In the first argument of `runEffect', namely `(undefined :: Either a ())' In the expression: runEffect (undefined :: Either a ()) In an equation for `run': run = runEffect (undefined :: Either a ()) }}} So it seems it's trying to unify Bool and () because it's unifying both a with Bool and a with (); however, the usual comments about rigid type variables aren't there, which makes even this error message a bit confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr
by GHC 22 Nov '13

22 Nov '13

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr ----------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Numerous ghci tests in the testsuite currently fail on ARM due to the lack of a `mkJumpToAddr` definition. These failures look like, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130927 for arm-unknown-linux): mkJumpToAddr not defined for ArchARM {armISA = ARMv7, armISAExt = FPv3,NEON], armABI = HARD} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As it turns out `mkJumpToAddr` is fairly straightforward to implement. I've done this in https://github.com/bgamari/ghc/tree/arm. This brings the number of unexpected failures in `tests/ghci` from 44 to 4. These four failures are segmentation faults that I need to look more closely at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8065: Set trac up for multiple git repos
by GHC 20 Nov '13

20 Nov '13

#8065: Set trac up for multiple git repos ------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | 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: | ------------------------------------+------------------------------------- Set trac up for multiple git repos: http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8212: ghc panic building vector on Raspberry Pi
by GHC 19 Nov '13

19 Nov '13

#8212: ghc panic building vector on Raspberry Pi -----------------------------+------------------------------------- Reporter: ill_logic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+------------------------------------- Configuring vector-0.10.0.1... Building vector-0.10.0.1... Preprocessing library vector-0.10.0.1... [ 1 of 19] Compiling Data.Vector.Storable.Internal ( Data/Vector/Storable/Internal.hs, dist/build/Data/Vector/Storable/Internal.o ) [ 2 of 19] Compiling Data.Vector.Fusion.Util ( Data/Vector/Fusion/Util.hs, dist/build/Data/Vector/Fusion/Util.o ) [ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size ( Data/Vector/Fusion/Stream/Size.hs, dist/build/Data/Vector/Fusion/Stream/Size.o ) Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Size' [ 4 of 19] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/build/Data/Vector/Internal/Check.o ) [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d ra42} pi@raspberrypi ~ $ uname -a Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux Let me know if there's any other details I can help with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8479: Generic1 crashes with tyConStupidTheta when using associated type families
by GHC 18 Nov '13

18 Nov '13

#8479: Generic1 crashes with tyConStupidTheta when using associated type families -------------------------------------+------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Generics, | Operating System: Unknown/Multiple Generic1 | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ {-# OPTIONS_GHC -Wall #-} {-# Language TypeFamilies #-} {-# Language DeriveGeneric #-} import GHC.Generics class Blah (a :: * -> *) where type F a :: * -> * data Foo (f :: * -> *) a = MkFoo ((F f) a) deriving Generic1 --data Foo a = MkFoo ((F f) a) deriving Generic1 -- also crashes }}} the above code crashes GHC with error: {{{ [1 of 1] Compiling Main ( GenericBug.hs, GenericBug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tyConStupidTheta main:Main.F{tc ro4} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8203: Yesod platform fails to build on ARM
by GHC 18 Nov '13

18 Nov '13

#8203: Yesod platform fails to build on ARM -----------------------------+--------------------------------- Reporter: randomist | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+--------------------------------- Trying to build yesod platform on Samsung Chromebook (architecture is armv7l), and get this crash in compiling the package vector-0.10.0.1: [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d ra42} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8339: Build fails with panic in vector
by GHC 18 Nov '13

18 Nov '13

#8339: Build fails with panic in vector ----------------------------------+---------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Operating System: Unknown/Multiple Keywords: vector | Type of failure: Building GHC failed annotation | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: #8203 #8212 | ----------------------------------+---------------------------------------- I get this on powerpc64 Linux but I suspect from the error message it affects all architectures without GHCi support: {{{"inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name vector-0.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist- install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -package primitive-0.4.0.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -no-user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist- install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130828 for powerpc64-unknown-linux): Cant do annotations without GHCi {libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d rcn} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8298: +RTS -hb crash when blocking on empty TChan
by GHC 14 Nov '13

14 Nov '13

#8298: +RTS -hb crash when blocking on empty TChan ------------------------------------------------+-------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: biographical stm tchan block | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Difficulty: Unknown | Runtime crash Blocked By: | Test Case: Related Tickets: | Blocking: ------------------------------------------------+-------------------------- Running the following code {{{ module Main where import Control.Concurrent import Control.Concurrent.STM main :: IO () main = do c <- newTChanIO forkIO . atomically $ readTChan c return () }}} produces: {{{ $ ./tmp +RTS -hb tmp: internal error: Invalid object in processHeapClosureForDead(): 0 (GHC version 7.6.3 for x86_64_unknown_linux) }}} It crashes without forkIO as well, I inserted it so that a plain run doesn't result in "thread blocked indefinitely in an STM transaction". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files
by GHC 13 Nov '13

13 Nov '13

#8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------+------------------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: | Milestone: 7.8.1 normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Driver | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider === A.hs-boot {{{ #!haskell module A where }}} === B.hs {{{ #!haskell module B where import {-# SOURCE #-} A }}} === Command Line {{{ $ ghc -c A.hs-boot B.hs B.hs:3:1: Bad interface file: A.hi-boot-boot A.hi-boot-boot: openBinaryFile: does not exist (No such file or directory) }}} I expect the modules to get compiled cleanly. Instead I get an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8433: forkProcess masks async exceptions inside the child process
by GHC 08 Nov '13

08 Nov '13

#8433: forkProcess masks async exceptions inside the child process ------------------------------------+--------------------------------- Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi- threaded daemon that expects async exceptions to work as they usually would. FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5