October 2013 - ghc-tickets

[GHC] #8359: ConstraintKinds require UndecidableInstances when it doesn't need it
by GHC 01 Oct '13

01 Oct '13

#8359: ConstraintKinds require UndecidableInstances when it doesn't need it ----------------------------+---------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Using ConstraintKinds to alias a bunch of class constraints fails to compile without UndecidableInstances. The same code that manually spells out class constraints without ConstraintKinds compiles just fine though. Test case below ------------------------------------- {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} class DifferentTypes a b type DifferentTypes3 a b c = (DifferentTypes a b, DifferentTypes b c, DifferentTypes a c) class Foo a class Bar a -- Buggy instance requires UndecidableInstances to compile instance (DifferentTypes3 a b c, Bar a, Bar b, Bar c) => Foo (a, b, c) -- Equivalent instance compiles when manually expanding constraint type instance (DifferentTypes a b, DifferentTypes b c, DifferentTypes a c, Bar a, Bar b, Bar c) => Foo (a, b, c) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8329: dmdTransformDictSelSig panic
by GHC 01 Oct '13

01 Oct '13

#8329: dmdTransformDictSelSig panic -----------------------------------+--------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Installing `xmlhtml` with HEAD panicks, while it works in 7.6.3. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130918 for x86_64-unknown-linux): dmdTransformDictSelSig: split failed }}} I reduced this panic to four files: Common.hs {{{ module Common where import Data.String (fromString) encodingName :: String encodingName = fromString "" }}} Meta.hs {{{ {-# OPTIONS_GHC -O0 #-} module Meta where import Data.String }}} Parse.hs {{{ module Parse where import Meta }}} XmlHtml.hs {{{ module XmlHtml where import Parse import Common }}} Remove *.hi and *.o files and compile `ghc -O XmlHtml` to get the panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8247: Dependency tracking (--make) broken for re-exported modules
by GHC 01 Oct '13

01 Oct '13

#8247: Dependency tracking (--make) broken for re-exported modules ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say, I re-export a module, from which I hide some bindings: {{{ module B (module A) where import A hiding (a1) }}} where `A` is defined thus: {{{ module A where a1 = 5 a2 = 42 a3 = 113 }}} I use `B` from `C`: {{{ module C where import B a2 = 142 }}} Build `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`). Now hide also `a2` in `B` like this (by editing `B.hs`): {{{ module B (module A) where import A hiding (a1, a2) }}} Build `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated. Deleting `B.hi` and recompiling resolves the situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7783: MultiWayIf should start a new layout
by GHC 01 Oct '13

01 Oct '13

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7783#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7783: MultiWayIf should start a new layout
by GHC 01 Oct '13

01 Oct '13

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:aab65608f9a26990b2c5083e4b65b9d1f6c9b48a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aab65608f9a26990b2c5083e4b65b9d1f6c9b48a" Add layout to MultiWayIf (#7783) This makes it possible to write x = if | False -> if | False -> 1 | False -> 2 | True -> 3 Layout normally inserts semicolons between declarations at the same indentation level, so I added optional semicolons to the syntax for guards in MultiWayIf syntax. This is a bit of a hack, but the alternative (a special kind of layout that doesn't insert semicolons) seemed worse, or at least equally bad. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7783#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8377: GHCi crashes with unboxed values on 32-bit platforms
by GHC 01 Oct '13

01 Oct '13

#8377: GHCi crashes with unboxed values on 32-bit platforms ---------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------+------------------------------------- The following program causes GHCi to crash, on x86 Linux and x86 Windows. {{{ {-# LANGUAGE MagicHash #-} import System.Mem import GHC.Base main = do let list = concatMap buildThunk [0..10000] length list `seq` performGC print $ last list buildThunk :: Int -> [Int] buildThunk (I# k) = [f k] f :: Int# -> Int f x = I# x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x
by GHC 01 Oct '13

01 Oct '13

#7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x -----------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Comment (by simonmar): Getting a stack trace would probably help. You want to make sure that GHC itself is built with `-debug`: set `GhcDebugged=YES` in your build.mk (this will slow down the build, but you can remove it later). When the process hangs, attach to it with gdb and get a backtrace of all the threads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7993#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7753: Profiling report broken with foreign exported functions
by GHC 01 Oct '13

01 Oct '13

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by akio): * status: new => patch Comment: I'm not sure if this is the best way to fix it, but the attached patch improves the output; now {{{wrapper}}} and {{{f}}} are placed directly under {{{MAIN}}}, and they get {{{inherited}}} costs correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7753#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7753: Profiling report broken with foreign exported functions
by GHC 01 Oct '13

01 Oct '13

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by akio): I think I know what is happening. The {{{wrapper}}} and {{{f}}} cost centres are actually placed under {{{SYSTEM}}}. I can see it by using {{{+RTS -pa}}} instead of {{{+RTS -p}}}. However {{{SYSTEM}}} is a hidden cost centre, so by default it's not included in the report, resulting in a confusing call tree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7753#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8129: Constraint solver panic when -ddump-tc-trace is used
by GHC 01 Oct '13

01 Oct '13

#8129: Constraint solver panic when -ddump-tc-trace is used -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} {-# OPTIONS_GHC -ddump-tc-trace #-} type family F (x :: *) :: * class (y ~ F x) => C x y z = () :: C x y => () }}} causes a panic while tracing the typechecker: {{{ solveNestedImplications starting { original inerts = Equalities: Type-function equalities: [D] _ :: F x_aeH ~ y_aeI (CFunEqCan) Dictionaries: [W] $dC_aeK :: C x_aeH y_aeI (CDictCan) Irreds: Insolubles = {} Solved dicts 0 Solved funeqs 0 thinner_inerts = Equalities:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130812 for i386-unknown-linux): No match in record selector ctev_evar }}} If `-ddump-tc-trace` is not used, the correct constraint solving error is generated: {{{ Could not deduce (C x0 y0) arising from the ambiguity check for an expression type signature from the context (C x y) bound by an expression type signature: C x y => () }}} It seems that `prepareInertsForImplications` in `TcSMonad` assumes that all the `inert_funeqs` are givens or wanteds; if there are some deriveds, then the above panic results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9