September 2015 - ghc-tickets

[GHC] #10539: ghc internal error compiling simple template haskell + lens program
by GHC 21 Sep '15

21 Sep '15

#10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: lens | Operating System: Linux template-haskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue. {{{#!sh Building language-arithmetic-0.1.0.0... Preprocessing library language-arithmetic-0.1.0.0... [1 of 2] Compiling Language.Arithmetic.Syntax ( src/Language/Arithmetic/Syntax.hs, dist/build/Language/Arithmetic/Syntax.o ) ghc: internal error: stg_ap_v_ret (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} {{{#!hs module Language.Arithmetic.Syntax where import Control.Applicative hiding (Const) import Control.Lens hiding (Const) import Control.Lens.Plated import Prelude hiding (const) import Data.Data data Arith a b c = Plus { _left :: (Arith a b c), _right :: (Arith a b c) } | Minus { _left :: (Arith a b c), _right :: (Arith a b c) } | Times { _left :: (Arith a b c), _right :: (Arith a b c) } | Divide { _left :: (Arith a b c), _right :: (Arith a b c) } | Modulo { _left :: (Arith a b c), _right :: (Arith a b c) } | Parens { _subexp :: (Arith a b c) } | FunCall{ _name :: String, _subexp :: (Arith a b c) } | Const { _const :: a} | Var { _var :: b } | Embed { _embed :: c } deriving (Show, Eq, Ord, Data, Typeable) makeLenses ''Arith instance Plated (Arith a b c) where plate = uniplate }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10837: Constant-time indexing of closed type family axioms
by GHC 21 Sep '15

21 Sep '15

#10837: Constant-time indexing of closed type family axioms -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Right now `CoAxiom` stores a list of `CoAxBranch`es in a `BranchList`. But it would be useful to actually have a constant-time indexing into axioms. One code fragment when I really wanted to have this feature is in `TcValidity.checkValidCoAxiom`: {{{#!hs -- Replace n-th element in the list. Assumes 0-based indexing. replace_br :: [CoAxBranch] -> Int -> CoAxBranch -> [CoAxBranch] replace_br brs n br = take n brs ++ [br] ++ drop (n+1) brs }}} I believe this code could be rewritten in a much more efficient way using constant-time indexing. The new data structure should most likely have a type that indicates whether the axiom is branched or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10837> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Sep '15

21 Sep '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Changes (by meteficha): * cc: felipe.lessa@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Sep '15

21 Sep '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192 -------------------------------------+------------------------------------- Comment (by meteficha): Assuming that the main source of non-deterministic Uniques is the non- deterministic, lazy I/O, how about making a different Unique "namespace" for each file? Conceptually, it would mean having: {{{#!hs data Unique = MkUnique {-# UNPACK #-} !Int (Maybe ModuleName) }}} There could still be problems if each file was processed in a non- deterministic way, but now files could be processed in any order without changing the Uniques. This is of course an extremely naive suggestion, I'm sharing it with the hope that it may spark some better idea in someone else's mind :). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 21 Sep '15

21 Sep '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by zardoz): * cc: zardoz (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10903: Add an option to infer CallStack implicit parameters
by GHC 21 Sep '15

21 Sep '15

#10903: Add an option to infer CallStack implicit parameters -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Adam Foltzer mentioned to me at ICFP that it would be nice if GHC had a "debug" mode that automatically inserted CallStack IPs in every function signature. Then you could easily get nice, fairly complete, call-stacks during development. Of course you could already do this with judicious use of CPP macros, but that's quite tedious (and error prone). As an example, consider {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" }}} Compiling `A` in this mode should result in the following signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} I have a few concerns with this though: 1. We're '''changing''' a type signature that the user wrote. It would be a well-defined and consistent change across the whole module, but it's still unsettling. 2. How do we handle a function that already has a CallStack IP? {{{#!hs bar :: (?stk :: CallStack) => [a] -> a }}} If we're aiming for consistent insertion of CallStacks everywhere, it might make sense to remove the `?stk :: CallStack` and insert a `?callStack :: CallStack`, so they'll be appended correctly. But here again we'd be changing a user-written type signature. Furthermore, `bar` might call a function from a different module (or package) that hasn't been given this consistent debug treatment, and this other module might expect that the CallStack be named `?stk`. 3. If the CallStack is not used, e.g. {{{#!hs null :: (?callStack :: CallStack) => [a] -> Bool null [] = True null (_:_) = False }}} it will trigger a redundant constraint warning. I think we could address this by bubbling up CallStack constraints in much the same way that other constraints are propagated, so {{{#!hs module A where foo xs = head xs head :: [a] -> a head (x:xs) = x head _ = error "bad" null [] = True null (_:_) = False }}} would get the signature {{{#!hs module A where foo :: (?callStack :: CallStack) => [a] -> a head :: (?callStack :: CallStack) => [a] -> a null :: [a] -> Bool }}} In other words, we would only infer a CallStack constraint for a function when the body induces a wanted CallStack constraint. 4. How would this interact with cabal packages? If I accidentally install a package in debug mode, all downsteam packages will be compiled against the CallStack-laden signatures. Seems like we might need a new "debug" way.. It's pretty clear to me that a debug mode would be useful (in fact I manually added a bunch of CallStacks to my code the other day, only to remove them once I was done debugging), but the concerns (particularly 4.) are substantial. There's also the question of how all of this interacts with the ongoing DWARF work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10811: Template Haskell does associated types poorly (printing & quoting)
by GHC 21 Sep '15

21 Sep '15

#10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | 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 TemplateHaskell, TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| class C a where type F a type F a = a |]) }}} I get {{{ [d| class C a where type family F a F a = a |] ======> Bug.hs:6:7: Warning: Cannot desugar this Template Haskell declaration: class C a where type family F a F a = a }}} There are two problems here: 1. This really should work. 2. The pretty-printer here omits the `type` on the default definition for `F`. (The word `family` is optional there, but isn't actually wrong.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10895: "no output will be generated" should be an error, not a warning.
by GHC 20 Sep '15

20 Sep '15

#10895: "no output will be generated" should be an error, not a warning. -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider a file "Test.hs" which has a "main" function but is declared as "module Test where..." If we attempt to compile it, we get the following warning: {{{ Warning: output was redirected with -o, but no output will be generated because there is no Main module. }}} This should be upgraded from a warning to an error. This would help e.g. Cabal, because such warnings do not lead to a failure of the wrapping Cabal process, which is confusing to end-users. For gory details, see e.g. discussion at https://github.com/haskell/cabal/issues/1847 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 20 Sep '15

20 Sep '15

#365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 20 Sep '15

20 Sep '15

#365: GHC dies silently with faulty preprocessor -------------------------------------+------------------------------------- Reporter: josefs | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1256 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T365 * differential: => Phab:D1256 Comment: Added a patch so it doesn't silently die. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0