- ghc-tickets - Haskell.org

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 12 Oct '16

12 Oct '16

#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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10458: GHCi fails to load shared object (the 'impossible' happened)
by GHC 11 Oct '16

11 Oct '16

#10458: GHCi fails to load shared object (the 'impossible' happened) -----------------------------------------+--------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi: {{{ % cabal repl Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get: {{{ % cabal repl --ghc-options="-fPIC" Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FYI the C type of `pcre_callout` is a little unusual: {{{ extern int (*pcre_callout)(pcre_callout_block *); }}} In other words it is a global variable (pointer to function), not a function itself. Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #12684: GHC panic due to bindnow linker flag
by GHC 11 Oct '16

11 Oct '16

#12684: GHC panic due to bindnow linker flag -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: 11238 Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As [https://ghc.haskell.org/trac/ghc/ticket/10458#comment:45 explained in #10458] our `haskell-opencv` library failed to build on NixOS-16.09 due to its recently introduced [https://nixos.org/nixpkgs/manual/#sec-hardening- in-nixpkgs hardening features]. Specifically the problem is that NixOS is setting the `-z bindnow` linker flag which causes the build to fail with: {{{ ... [33 of 64] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1001/ghc8697_0/libghc_200.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa }}} Fortunately this flag can be [https://github.com/LumiGuide/haskell- opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4 disabled] so I'm now able to build the library successfully. However, it would be nice if GHC is able to work around this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12559: Don't ignore addTopDecls in addModFinalizer
by GHC 10 Oct '16

10 Oct '16

#12559: Don't ignore addTopDecls in addModFinalizer -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: template- | Operating System: Unknown/Multiple haskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11832 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program fails to compile because `f` is not found. {{{ -- main.hs import M main = print (f 0) }}} {{{ -- M.hs {-# LANGUAGE TemplateHaskell #-} module M where import Language.Haskell.TH.Syntax g :: IO () g = $(do addModFinalizer (do d <- [d| f x = (2 :: Int) |]; addTopDecls d) [| return ()|] ) }}} {{{ $ runghc main.hs main.hs:3:15: Not in scope: ‘f’ }}} This bug is problematic to produce top-level declarations which depend on the output of `reify` for local variables, which can only run in `addModFinalizer`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12672: Missing lambda in third monad law description
by GHC 10 Oct '16

10 Oct '16

#12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: documentation | Operating System: Unknown/Multiple monad | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Control.Monad` documentation is missing the lambda in the documentation for the third monad law because it is not escaped with an additional `\`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 10 Oct '16

10 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Sadly it looks like this won't be fixed for 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12682: ASSERT failures in testsuite
by GHC 10 Oct '16

10 Oct '16

#12682: ASSERT failures in testsuite -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Joachim [https://mail.haskell.org/pipermail/ghc- devs/2016-October/013000.html writes]: our secondary CI infrastructure is in bad shape since a week. The first push that broke it was the one ending with commit fc4ef66 by SPJ: * fc4ef66 - Comments only (vor 7 Tagen)<Simon Peyton Jones> * b612da6 - Fix impredicativity (again) (vor 7 Tagen)<Simon Peyton Jones> * 3012c43 - Add Outputable Report in TcErrors (vor 7 Tagen)<Simon Peyton Jones> * 66a8c19 - Fix a bug in occurs checking (vor 7 Tagen)<Simon Peyton Jones> * 2fbfbca - Fix desugaring of pattern bindings (again) (vor 7 Tagen)<Simon Peyton Jones> * 0b533a2 - A bit of tracing about flattening (vor 7 Tagen)<Simon Peyton Jones> {{{ --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ /tmp/ghctest-gSX4vv/test spaces/./boxy/Base1.run/Base1.comp.stderr.normalised 2016-09-30 12:44:57.182659875 +0000 @@ -0,0 +1,18 @@ + +Base1.hs:20:13: + Couldn't match type â€˜a0 -> a0â€™ with â€˜forall a. a -> aâ€™ + Expected type: MEither Sid b + Actual type: MEither (a0 -> a0) b + In the expression: MLeft fid + In an equation for â€˜test1â€™: test1 fid = MLeft fid + +Base1.hs:25:39: + Couldn't match type â€˜a1 -> a1â€™ with â€˜forall a. a -> aâ€™ + Expected type: Maybe (Sid, Sid) + Actual type: Maybe (a1 -> a1, a2 -> a2) + In the expression: Just (x, y) + In a case alternative: MRight y -> Just (x, y) + In the expression: + case m of { + MRight y -> Just (x, y) + _ -> Nothing } *** unexpected failure for Base1(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_aAI Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell… *** unexpected failure for RaeBlogPost(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_awK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell… *** unexpected failure for TypeLevelVec(normal) }}} A subsequent commit by SPJ fixed the first one. It now compield without -DDEBUG again, but the other two failures (observable only with -DDEBUG) are still there. Since then, Travis has been reporting failures for the master branch. I only noticed now as I pushed something to master, and I got an email. Did you not get notifications about the breakage? If you did, was it unclear how to get to the log file? In any case: Simon, could you have a look and see if the ASSERT is pointing out a real bug introduced with your commits, or whether the ASSERT is wrong, so that we can build master with -DDEBUG again? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12682> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 10 Oct '16

10 Oct '16

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Oops, this was incorrectly closed; the performance regression is still present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1969: enormous compile times
by GHC 10 Oct '16

10 Oct '16

#1969: enormous compile times -------------------------------------------------+------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12 | branch Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: | performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: T1969 -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"cc5ca21b6595d550b27439699cc223c7b0ceab61/ghc" cc5ca21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc5ca21b6595d550b27439699cc223c7b0ceab61" Improved stats for Trac #1969 With my latest commits 76a5477 Move zonking out of tcFamTyPats b255ae7 Orient improvement constraints better perf has improved slightly for T1969: allocs: 733M -> 26M residency: 43M -> 41M I don't know exactly why, but hey, it's good }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1969#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12683: Monad laws in terms of fishes (>=>)
by GHC 10 Oct '16

10 Oct '16

#12683: Monad laws in terms of fishes (>=>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12672 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Present monad laws with Kleisli composition (fish operator) {{{#!hs return >=> g = g g >=> return = g (f >=> g) >=> h = f >=> (g >=> h) }}} instead of bind: {{{#!hs return a >>= k = k a m >>= return = m m >>= (\x -> k x >>= h) = (m >>= k) >>= h }}} Even though `>>=` is a method of `Monad` this is so much clearer that I think it's worth it, started as ticket:12672#comment:4 ---- Fun mention: [http://www.cse.chalmers.se/~jomoa/papers/quickspec2016.pdf QuickSpec] doesn't generate lambda terms so it will not discover `(xs >>= f) >>= g` = `xs >>= (\x -> f x >>= g)` so it needs to be in terms of `>=>`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0