February 2014 - ghc-tickets

[GHC] #8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes
by GHC 17 Feb '14

17 Feb '14

#8758: GeneralizedNewtypeDeriving sometimes needs RankNTypes -------------------------------------------+------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE RankNTypes #-} module A where class C m where foo :: (forall b. b -> m b) -> c -> m c instance C [] where foo f c = f c }}} and {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype MyList a = Mk [a] deriving C }}} When I compile B.hs, I get {{{ Illegal polymorphic or qualified type: forall b. b -> MyList b Perhaps you intended to use RankNTypes or Rank2Types In an expression type signature: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c In the expression: GHC.Prim.coerce (foo :: (forall (b :: *). b -> [] b) -> c -> [] c) :: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c In an equation for ‛foo’: foo = GHC.Prim.coerce (foo :: (forall (b :: *). b -> [] b) -> c -> [] c) :: forall (c :: *). (forall (b :: *). b -> MyList b) -> c -> MyList c }}} I will fix shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8759: Pattern synonyms and TH
by GHC 17 Feb '14

17 Feb '14

#8759: Pattern synonyms and TH -----------------------------------+--------------------------------------- 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: | -----------------------------------+--------------------------------------- This file {{{ {-# LANGUAGE PatternSynonyms, TemplateHaskell #-} x = [d|pattern P = ()|] }}} causes a panic. Until TH supports pattern synonyms we should give a sensible error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8744: "Thread-local storage not supported" for Mac
by GHC 17 Feb '14

17 Feb '14

#8744: "Thread-local storage not supported" for Mac ----------------------------------+---------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- On a fresh clone of HEAD, building eventually gets me {{{ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc- Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc- Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc- Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc- DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_thr\" -optc- funroll-loops -static -optc-DTHREADED_RTS -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/sm/Evac.c -o rts/dist/build/sm/Evac.thr_o In file included from rts/sm/Evac.c:21:0: rts/sm/GCTDecl.h:71:0: error: thread-local storage not supported for this target }}} I'm on Mac OS 10.8.5, Xcode 4.6.1 (4H512), bootstrapping from 7.6.3, with `BuildFlavour = devel2`. With this report, my build is dead in the water. (Separately, Trac doesn't have an option for reporting a bug in version 7.9!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8788: Remove old comment
by GHC 17 Feb '14

17 Feb '14

#8788: Remove old comment ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- See attachment -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 Feb '14

17 Feb '14

#4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nomeata): Ah, I just see that #8144 was actually fixed after 7.6. I’ll shut up and report back when 7.8 has hit the Debian archives... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 Feb '14

17 Feb '14

#4012: Compilation results are not deterministic ----------------------------------+---------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 days) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | ----------------------------------+---------------------------------------- Comment (by nomeata): Debian is (slowly, as usual) working towards reproducible builds, and while some Haskell packages satisfy that requirement, others do not – see this message: https://lists.debian.org/debian- haskell/2014/02/msg00011.html What I find interesting is that `--show-iface` shows now change at all, besides a different interface hash. It would make debugging these issues easier if everything that takes part in the hash calculation was visible in `--show-iface`. Off your head, any idea what else could contribute to a interface change? Built paths and time stamps contribute ''not'' towards the hash, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 17 Feb '14

17 Feb '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: merge Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by thoughtpolice): * version: 7.6.1-rc1 => 7.8.1-rc1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4959: Warning about variables with leading underscore that are used anyway
by GHC 16 Feb '14

16 Feb '14

#4959: Warning about variables with leading underscore that are used anyway -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 (Parser) | Keywords: warning unused Resolution: | underscore variable Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:6 goldfire]: > I don't have too strong an opinion here, but I want to note that sometimes the use of a variable with a leading underscore is intentional. In particular, I have found this necessary when I use CPP to optionally disable a certain chunk. I don't want warnings to appear when I disable the chunk (eliminating the one use of a variable, to which I prepend a `_`) or when I enable the chunk (now using a variable with a leading underscore). Could you move the conditionally used variable into the `#ifdef` block? > So, I have a slight preference for "no change" here, but it really is a slight preference -- I do see and understand the original poster's point. It should be possible to disable the used-underscore-warning. If the CPP problem arises often and is hard to workaround, then it would be still great to enable the used-underscore-warning on demand. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4959#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1475: Adding imports and exports with Template Haskell
by GHC 15 Feb '14

15 Feb '14

#1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by charmander): * cc: campersander@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1475#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2915: Arity is smaller than need be
by GHC 14 Feb '14

14 Feb '14

#2915: Arity is smaller than need be --------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): If we eta-expand to: {{{ h x = let f = \y -> case x of { True -> t1 y; False -> t2 y } in (f,f) }}} then we'd do the `case x` each time we call `f`, rather than once. But in exchange we get better code for `f`. Worth a try perhaps. Notice that we do such things between lambdas: {{{ h x = let g = \y -> case x of { True -> \v->e1; False -> \v->e2 } in ... }}} here we do (already) eta-expand g to {{{ h x = let g = \y v -> case x of { True -> e1; False -> e2 } in ... }}} This seems inconsistent with not doing so in for `f`. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2915#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0