October 2015 - ghc-tickets

[GHC] #10995: Existentials in newtypes
by GHC 21 Oct '15

21 Oct '15

#10995: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles: {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies, RankNTypes, PolyKinds, KindSignatures #-} import GHC.Prim import Data.Proxy type family Ctx2 ctx a b :: Constraint newtype Proxy1 c a = P1 (forall b . Ctx2 c a b => Proxy b -> Int) }}} but if I explicitly poly-kind `Ctx2`: `type family Ctx2 ctx a (b :: k) :: Constraint` I get the errors {{{ Main.hs:10:22: Could not deduce (b ~ b0) from the context (Ctx2 c a b) bound by the type of the constructor ‘P1’: Ctx2 c a b => Proxy b -> Int at Main.hs:10:22 ‘b’ is a rigid type variable bound by the type of the constructor ‘P1’: Ctx2 c a b => Proxy b -> Int at Main.hs:10:22 Expected type: Proxy b -> Int Actual type: Proxy b0 -> Int In the ambiguity check for the type of the constructor ‘P1’: P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ‘P1’ In the newtype declaration for ‘Proxy1’ Main.hs:10:22: A newtype constructor cannot have existential type variables P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a In the definition of data constructor ‘P1’ In the newtype declaration for ‘Proxy1’ }}} It seems like the code should compile, but I might be missing something. This ticket is really about the second error message: there were existential types in a newtype before and after the change, so this error should occur in both places or neither. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO
by GHC 21 Oct '15

21 Oct '15

#10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Current git HEAD has failing tests after Phab:D975 when compiling with `DYNAMIC_GHC_PROGRAMS = NO`. {{{ Unexpected failures: ghci.debugger/scripts break001 [bad exit code] (ghci) ghci.debugger/scripts break005 [bad exit code] (ghci) ghci.debugger/scripts break006 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad exit code] (ghci) ghci.debugger/scripts break017 [bad exit code] (ghci) ghci.debugger/scripts dynbrk007 [bad exit code] (ghci) ghci.debugger/scripts hist001 [bad exit code] (ghci) ghci.debugger/scripts print001 [bad exit code] (ghci) ghci.debugger/scripts print002 [bad exit code] (ghci) ghci.debugger/scripts print003 [bad exit code] (ghci) ghci.debugger/scripts print004 [bad exit code] (ghci) ghci.debugger/scripts print005 [bad exit code] (ghci) ghci.debugger/scripts print006 [bad exit code] (ghci) ghci.debugger/scripts print008 [bad exit code] (ghci) ghci.debugger/scripts print010 [bad exit code] (ghci) ghci.debugger/scripts print011 [bad exit code] (ghci) ghci.debugger/scripts print012 [bad exit code] (ghci) ghci.debugger/scripts print013 [bad exit code] (ghci) ghci.debugger/scripts print016 [bad exit code] (ghci) ghci.debugger/scripts print017 [bad exit code] (ghci) ghci.debugger/scripts print019 [bad exit code] (ghci) ghci.debugger/scripts print020 [bad exit code] (ghci) ghci.debugger/scripts print023 [bad exit code] (ghci) ghci.debugger/scripts print024 [bad exit code] (ghci) ghci.debugger/scripts print026 [bad exit code] (ghci) ghci.debugger/scripts print028 [bad exit code] (ghci) ghci.debugger/scripts print031 [bad exit code] (ghci) ghci.debugger/scripts print032 [bad exit code] (ghci) ghci.debugger/scripts print034 [bad exit code] (ghci) ghci/scripts T2976 [bad exit code] (ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #602: Warning Suppression
by GHC 21 Oct '15

21 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Jeremy mentions in https://mail.haskell.org/pipermail/libraries/2015-October/026376.html: .NET has a very flexible system for suppressing code analysis warnings, it may be informative for formulating a GHC solution. https://msdn.microsoft.com/en-us/library/ms244717.aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10899: Polytype accepted in RHS of default associated type
by GHC 21 Oct '15

21 Oct '15

#10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This hogwash is accepted: {{{ class C a where type F a type F a = forall m. m a }}} I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10817: Looping default associated type family without UndecidableInstances
by GHC 21 Oct '15

21 Oct '15

#10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy class C a where type F a type F a = F a instance C Bool x :: Proxy (F Bool) x = Proxy }}} GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10672: checkProddableBlock crash during Template Haskell linking
by GHC 21 Oct '15

21 Oct '15

#10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9297 #10563 Differential Revisions: | #8237 -------------------------------------+------------------------------------- When compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes: {{{ [2 of 2] Compiling Main ( app\Main.hs, dist\build\main\main- tmp\Main.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000360564 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've boiled this down into a minimal reproduction of a library that includes a .cpp file, and an executable that depends on it. To test: {{{ git clone https://github.com/lukexi/cxx-link-fail-repro cabal run }}} The crash does not occur in the repro unless I use C++ exceptions in the library, and use Template Haskell in the executable, but in the project I boiled this down from (http://github.com/lukexi/bullet-mini) the problem occurs even with {{{cc-options: -fno-exceptions}}}. Some more details are at https://github.com/lukexi/cxx-link-fail-repro The platform is Windows 8.1 under MSYS2 (GHC is still using its inbuilt mingw). I've also tried 7.10.2-RC1 with the same result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10225: GHC does not specialize based on type equality
by GHC 21 Oct '15

21 Oct '15

#10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Based on my testing, it seems that if I have a function like f :: (v ~ V2) => v -> v this will be slower than f :: v -> v It would be great if GHC could do this optimization. The reason I want this is that I have written some very generic functions in my program, which are actually only used for one type. SPECIALIZE doesn't seem to do enough, as it's hard to get those GHC to "see" all of those types. As a compromise, I tried to tell GHC what those types actually are via type equalities, so that I can keep type constraints around for the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10258: internal error: evacuate: strange closure type 3269
by GHC 21 Oct '15

21 Oct '15

#10258: internal error: evacuate: strange closure type 3269 -------------------------------------------+------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- When trying to load the attatched source into GHCi, it spit out the following error: {{{ ghc.exe: internal error: evacuate: strange closure type 3269 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} I could not reproduce the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306
by GHC 21 Oct '15

21 Oct '15

#8957: ghci's :l -> internal error: evacuate: strange closure type 8306 ----------------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- GHCi crashes when :loading a file. Unfortunately I can't reproduce the bug, so this one's gonna be lots of information that probably will help very little. This is the actual error message: {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) <interactive>: internal error: evacuate: strange closure type 8306 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This one was the error I was working on, i.e. the (legit) error in the previous call: (Including this because it gives you a clue what I was working on, I was mostly fiddling around with parens in placeAgents' gnd function) {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) [2 of 2] Compiling SimpleCellularALife ( SimpleCellularALife.hs, interpreted ) SimpleCellularALife.hs:70:28: Couldn't match expected type `Array i0 e0' with actual type `Ground' In the return type of a call of `ground' In the first argument of `(!)', namely `ground (tiles w)' In the expression: (ground (tiles w) ! (fst $ head grp)) SimpleCellularALife.hs:70:36: Couldn't match expected type `Tile' with actual type `Array Coordinates Tile' In the return type of a call of `tiles' In the first argument of `ground', namely `(tiles w)' In the first argument of `(!)', namely `ground (tiles w)' Failed, modules loaded: CommonStatistics. }}} Included Source Files - CommonStatistics.hs: {{{ module CommonStatistics where type Memory = [Int]--Internal state of an Agent. data StatUpdate = StatUpdate{ newVictories :: [Int] -- by agentID } deriving (Show) data Agent = Agent{ agentID :: Int, sourcePath :: FilePath, --path to .hs source file. relative to executable doFunc :: [String] -> Memory -> (Memory, [String]), evFunc :: [String] -> Memory -> (Memory, String), personalMemory :: Memory } instance Show Agent where show (Agent { agentID = aID, sourcePath = path, doFunc = forgetit, evFunc = forgetittoo, personalMemory = mem }) = show (aID, path, mem) }}} And SimpleCellularALife.hs: (I am not exactly confident that this is the version that caused the error. I sadly can't reproduce it, so there's no confirming that. {{{ module SimpleCellularALife where import Data.Array import Data.List import System.Random import CommonStatistics data Ground = Ground { food :: Int } data Entity = Entity{ ai :: Agent, health :: Int } data Tile = Tile{ ground :: Ground, entities :: [Entity] } data World = World { tiles :: Array Coordinates Tile } type Coordinates = (Int, Int) getRandomPosition :: RandomGen t => World -> t -> (t, Coordinates) getRandomPosition w rand = let ((minx, miny), (maxx, maxy)) = bounds $ tiles w (x, rand2) = randomR (minx, maxx) rand (y, rand3) = randomR (miny, maxy) rand2 in (rand3, (x, y)) placeAgents :: RandomGen t => World -> [Agent] -> t -> (t, World) placeAgents w agents rand = let createTileUpdates (ag:ags) wrld rnd = let (rnd2, coords) = getRandomPosition wrld rnd (rnd3, restUpd) = createTileUpdates ags wrld rnd2 in (rnd3, (coords, ag) : restUpd) createTileUpdates [] wrld rnd = (rnd, []) (rand2, assocList) = createTileUpdates agents w rand groupedAssocList = groupBy (\(c1, a1) (c2, a2) -> c1 == c2) $ sortBy (\(c1, a1) (c2, a2) -> compare c1 c2) assocList gnd grp = ground ((tiles w) ! (fst $ head grp)) condenseGroup grp = (fst $ head grp, Tile{ground = gnd grp, entities = snd $ unzip grp}) --map condenseGroup groupedAssocList --::(Coordinates, Tile) in (rand, w) --placeAgents (placeAgent w firstAg x y) agents rand3 }}} Someone suggested that this might've been GHCI running out of memory. I am as of writing this at 66% out of 4GB used. The GHCI instance was opened for an extended period of time, so it might have racked up quite a bit of RAM usage. I can say though that considering the file sizes, 1.3GB of RAM usage seems unreasonable. And because I haven't yet written enough, here are all the variations of the line I was working on that could've caused it. Pulled them out of my text editor's buffer. {{{ gnd grp = (ground (tiles w) ! fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp)) gnd grp = (ground ((tiles w) ! (fst $ head grp)) gnd grp = ground ((tiles w) ! (fst $ head grp)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8687: Strange closure type 9983
by GHC 21 Oct '15

21 Oct '15

#8687: Strange closure type 9983 ------------------------------------+------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- {{{ *Main> :main C:\\Windows\\Media\\onestop.mid <interactive>: internal error: evacuate: strange closure type 9983 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This happened to me on {{{ghci playmidi.hs}}} from the {{{examples/}}} folder of {{{http://hackage.haskell.org/package/hmidi-0.2.1.0}}} (downloaded the tar and fixed the parsec import, removing the {{{"parsec2"}}} package import and fixing a type checking error, replacing {{{selectOutputDevice Nothing}}} by {{{selectOutputDevice "Select midi output device" Nothing}}}. (We also fixed those compile errors at https://github.com/vahokif/hmidi/tree/2124a8.) I have not been able to reproduce it since the first time :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3