July 2014 - ghc-tickets

[GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies
by GHC 03 May '18

03 May '18

#8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies ------------------------------------+------------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- The code is: {{{ data K = Foo | Bar data D1 :: K -> * where F1 :: D1 Foo B1 :: D1 Bar class C (a :: K -> *) where data D2 a :: K -> * foo :: a k -> D2 a k -> Bool instance C D1 where data D2 D1 k where F2 :: D2 D1 Foo B2 :: D2 D1 Bar foo F1 F2 = True foo B1 B2 = True }}} With -Wall it gives the warning: {{{ Test.hs:23:5: Warning: Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: F1 B2 B1 F2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8853: Alarming looking warning about non-exhaustive pattern
by GHC 03 May '18

03 May '18

#8853: Alarming looking warning about non-exhaustive pattern -------------------------+------------------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The attached code produces this alarming warning: ~/waste$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ‘takeFromInv’: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... ~/waste$ ./AlarmingPattern AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns in function takeFromInv -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8494: Warn if a pattern guard obviates all others
by GHC 03 May '18

03 May '18

#8494: Warn if a pattern guard obviates all others -------------------------+------------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: | Milestone: feature request | Version: 7.6.3 Priority: | Operating System: Unknown/Multiple normal | Type of failure: Incorrect warning at Component: | compile-time Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The following code, when compiled with `-Wall`, gives no warnings: {{{ module Main where main :: IO () main = print $ foo (10 :: Int) where foo x | True = (20 :: Int) | x == 10 = (30 :: Int) }}} I would expect that since the pattern guard `| True` obviates the following guards, that it would warn about unreachable code. There was a bug in my code today which I tracked down to a code transposition that would have been easily spotted with such a warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8406: Invalid object in isRetainer() or Segfault
by GHC 25 Apr '18

25 Apr '18

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9307: wave4main in nofib fails
by GHC 14 Apr '18

14 Apr '18

#9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: MacOS X Keywords: wave4main | Type of failure: Incorrect result Architecture: x86_64 (amd64) | at runtime Difficulty: Unknown | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS. {{{ HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== wave4main: size of wave4main follows... __TEXT __DATA __OBJC others dec hex 4091904 450560 0 4295947176 4300489640 1005443a8 ==nofib== wave4main: time to run wave4main follows... ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; real 0m0.217s user 0m0.191s sys 0m0.011s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.197s user 0m0.186s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.190s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.200s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 make: *** [runtests] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families
by GHC 12 Apr '18

12 Apr '18

#8165: Use GeneralizedNewtypeDeriving to automatically create associated type families ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Here's a simple example: {{{ class C a where type T a instance C Int where type T Int = Bool newtype NT = NT Int deriving C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
by GHC 10 Apr '18

10 Apr '18

#8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I get the following error... {{{ <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) }}} When running following program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import qualified Data.Text.IO as T main = T.putStrLn "čušpajž日本語" }}} Was tested in #haskell and I have all the UTF-8 Settings set and so forth. It compiles just fine, but crashes during runtime. gcc -v: {{{ Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.4/4.2.1/specs Target: amd64-unknown-openbsd5.4 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8542: Suggest NegativeLiterals
by GHC 13 Mar '18

13 Mar '18

#8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | 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: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8772: ghci should safe history more often
by GHC 05 Mar '18

05 Mar '18

#8772: ghci should safe history more often ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It is very annoying if `ghci` crashes (due to using a foreign library wrongly, for example), and then the history is lost. It should be simple to save each line to history before it is being executed. Maybe a good task for new contributors? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5