December 2015 - ghc-tickets

[GHC] #9182: Empty case analysis for function clauses
by GHC 20 Jan '16

20 Jan '16

#9182: Empty case analysis for function clauses ------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Thanks to `-XEmptyCase`, the following is legal: {{{ module Empty where data Empty empty :: Empty -> a empty x = case x of { } }}} However, if I leave off the last line, GHC will complain that `The type signature for ‘empty’ lacks an accompanying binding`. I think this program should be accepted. It isn't that I'm not giving a definition for `empty`; it's that I'm defining it to be a function with no accompanying equations, as could be represented in Template Haskell by $(return [FunD (mkName "empty") []]) Currently, this too is rejected, with GHC complaining `Function binding for ‘empty’ has no equations`. I think this should be legal, with an empty list of clauses in a function definition being treated the same way as an empty list of matches in a case expression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9202: Strange Closure Type
by GHC 20 Jan '16

20 Jan '16

#9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strange-closure- | Operating System: Linux type | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Project (more | Test Case: than a week) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello masters of the universe, I am here with a plea. I have recently installed GHC 7.8.2 and cabal-install 1.20.0.0 (following [https://gist.github.com/wting/8498731 this] guide), and have ran into a fun road block on the way to installing yesod-platform. I have had a few incidents of the 'strange closure type ###' error on this machine before, on the 7.6.x version available in Ubuntu's repository. I believe this failure is occuring when installing text, because that was the error that I got when installing attoparsec alone, but without a sandbox. I know (barely) better now, so when I went to install yesod-platform, I did a {{{cabal unpack $1 && cd $1* && cabal sandbox init && cabal install --only-dependencies && cabal build}}}, but I failed at preventing the error, still :( I've attached the output as output.txt, and I've also included my `lspci` and `lshw` outputs just for giggles :) I hope someone can direct me in the right direction, I would appreciate it tremendously. Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10581: Recommend ScopedTypeVariables
by GHC 20 Jan '16

20 Jan '16

#10581: Recommend ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: goldfire | 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: | -------------------------------------+------------------------------------- The !ScopedTypeVariables extension is one of the few that doesn't recommend itself when it should be used. I recognize that this may be hard to do, but here is a strawman proposal: Always behave as if !ScopedTypeVariables is on at binding sites for type variables (in an annotation with `forall`). Then, at ''occurrences'' of type variables, check if the extension is on. If a type variable is in scope but the extension is off, remember that the user probably wants the extension, but then rename the type variable occurrence away from the in- scope one. If a type error ensues, we've remembered that the lack of !ScopedTypeVariables may be to blame, and we recommend turning it on. There may be better approaches, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives
by GHC 18 Jan '16

18 Jan '16

#10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: parallelim | 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 example code in GHC 7.10.2 docs "7.28. Concurrent and Parallel Haskell", then in "7.15.4. Annotating pure code for parallelism" the recommendation is to use `par` and `pseq`. These primitives pre-dates the strategy combinators `rpar` and `rseq`. The example given is: {{{#!hs import Control.Parallel nfib :: Int -> Int nfib n | n <= 1 = 1 | otherwise = par n1 (seq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) }}} The paper "Seq no more: Better Strategies for Parallel Haskell" ([http://www.macs.hw.ac.uk/~hwloidl/publications/strategies10.pdf] advocates `Eval` as an "evaluation order" monad, as preferable (versus `par` and `seq`) for loose control of evaluation order of parallelism. Moreover, Simon Marlow's "Parallel and Concurrent Programming in Haskell" doesn't mention the `par` and `seq` primitives at all. Should the GHC docs for "Concurrent and Parallel Haskell" encourage the use Eval combinators, either in addition to or instead of the `par` and `seq` primitives? I'd be happy to contribute an update to the docs if people agree to a shift in emphasis towards the Eval monad in the docs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11058: selected processor does not support ARM mode
by GHC 18 Jan '16

18 Jan '16

#11058: selected processor does not support ARM mode --------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building GHC-7.10.3-rc1 on Debian armel produces: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 }}} According to Austin, this is fallout from changeset:933adc0f31164cb651d11ecfcfe612ac429f714f/ghc / #10375. But it is also a regression from GHC-7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11252: :kind command hides the explicit kind
by GHC 18 Jan '16

18 Jan '16

#11252: :kind command hides the explicit kind ----------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: TypeInType | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- {{{#!hs -- /tmp/test.hs {-# LANGUAGE TypeInType #-} data Proxy1 k (a :: k) = P1 data Proxy2 (a :: k) = P2 }}} if I load the following into ghci (head) the `:kind` command gives the same result {{{#!haskell % ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> :kind Proxy1 :kind Proxy1 Proxy1 :: k -> * *Main> :kind Proxy2 :kind Proxy2 Proxy2 :: k -> * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11093: T9579 fails on OS X
by GHC 18 Jan '16

18 Jan '16

#11093: T9579 fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- As pointed out in ticket:9579#comment:19 the testcase T9579 fails on OS X, {{{ Actual stdout output differs from expected: --- ./T9579_outofheap_rtsall.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 +++ ./T9579_outofheap_rtsall.run.stdout.normalised 2015-06-16 14:06:15.000000000 -0400 @@ -1,4 +1,4 @@ T9579_outofheap_rtsall: Heap exhausted; -T9579_outofheap_rtsall: Current maximum heap size is NUM bytes (1 MB). +T9579_outofheap_rtsall: Current maximum heap size is 1048576 bytes (1 MB). T9579_outofheap_rtsall: Use `+RTS -M<size>' to increase it. 251 \ No newline at end of file *** unexpected failure for T9579_outofheap_rtsall(normal) }}} The issue appears to be a difference in `sed`'s behavior on OS X. The number in the error message is supposed to be replaced by `NUM` with `sed -e 's/[0-9]* bytes/NUM bytes/g'`. Perhaps someone with access to an OS X box could shed some light on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11300: outofmem RTS testcase fails on ARM
by GHC 18 Jan '16

18 Jan '16

#11300: outofmem RTS testcase fails on ARM --------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- The `outofmem` RTS testcase fails on ARM, {{{ =====> outofmem(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory outofmem </dev/null > outofmem.run.stdout 2> outofmem.run.stderr Actual stdout output differs from expected: --- ./outofmem.stdout.normalised 2015-12-27 17:21:08.718240403 +0100 +++ ./outofmem.run.stdout.normalised 2015-12-27 17:21:08.718240403 +0100 @@ -1 +1 @@ -exit(251) \ No newline at end of file +exit(1) \ No newline at end of file *** unexpected failure for outofmem(normal) }}} In particular, {{{ $ make outofmem make[1]: Entering directory '/mnt/ext/exp/ghc/testsuite/tests/rts' '/mnt/ext/exp/ghc/inplace/test spaces/ghc-stage2' -fforce-recomp -dcore- lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn- tabs -fno-warn-missed-specialisations -v0 --make -fforce-recomp outofmem.hs -o outofmem make[1]: Leaving directory '/mnt/ext/exp/ghc/testsuite/tests/rts' outofmem: out of memory (requested 1074790400 bytes) exit(1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10921: weird "optimisation levels" in man page
by GHC 17 Jan '16

17 Jan '16

#10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: manpage, | Operating System: Unknown/Multiple newcomer | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Man page shows this: {{{ Optimisation levels -O0 -O -O or -O1 -O0 -O2 -O0 -Odph }}} This looks very weird: - Why -O and -O0 listed twice? - That `or` looks weird, how do I read that? Apparently the man page is auto-generated from the user manual(thanks @int-e), and while doing that "reverse" column is also included. We should probably either ignore "reverse" column while parsing the user manual parts or somehow re-format generated man page lines. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8114: GHC panic when building `thyme`
by GHC 16 Jan '16

16 Jan '16

#8114: GHC panic when building `thyme` -----------------------------------+--------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- While attempting to build `thyme` from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log. {{{ rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc /usr/local/bin/ghc rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal /Users/Alexander/Library/Haskell/bin/cabal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8