October 2015 - ghc-tickets

[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] #9951: OverloadedLists breaks exhaustiveness check
by GHC 03 May '18

03 May '18

#9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE OverloadedLists #-} module Bug where f :: [a] -> () f x = case x of [] -> () (_:_) -> () }}} GHC reports: {{{ bug.hs:6:7: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: [] }}} This is reproducible with 7.8 and 7.10rc1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10116: Closed type families: Warn if it doesn't handle all cases
by GHC 03 May '18

03 May '18

#10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now, I can do the following: data Foo = A | B type family Bar (n :: 'Foo) where Bar 'A = Int I would like to be warned if I write a partial type function like this because partial functions are almost always a mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10393: Bogus warning with OverloadedLists
by GHC 03 May '18

03 May '18

#10393: Bogus warning with OverloadedLists -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE OverloadedLists #-} lgo :: [a] -> () lgo [] = () lgo (_:_) = () }}} I get {{{ /Users/rae/temp/Bug.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘lgo’: Patterns not matched: [] }}} I don't know !OverloadedLists deeply, but that warning surely is confusing! Happens on both 7.8.3 and 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #10296: Segfaults when using dynamic wrappers and concurrency
by GHC 25 Apr '18

25 Apr '18

#10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function. After much sweat I've managed to produce a self-contained program that exhibits the same behavior: {{{ bitonic@clay /tmp/ptr-crash % uname -a Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux bitonic@clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411 Resolving dependencies... Configuring ptr-crash-0... bitonic@clay /tmp/ptr-crash % cabal build Building ptr-crash-0... Preprocessing executable 'ptr-crash' for ptr-crash-0... [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- crash-tmp/Main.o ) Linking dist/build/ptr-crash/ptr-crash ... bitonic@clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr- crash/ptr-crash +RTS -N2 -RTS [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS }}} I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later. More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this): * The segfault only happens when using `-N2` or more. * Curiously, the segfault seems to happen much more often when compiling the program with `-g`. * `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`. * `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern. Sergei had a hunch that this had to do with thread-unsafe calls to `mremap`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc
by GHC 24 Apr '18

24 Apr '18

#9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When building ghc, I'm getting warnings about __sync_fetch_and_nand that the semantics have changed for gcc 4.4+. I'm building on Windows, but I don't think that matters. Is this an indication of a problem or does that warning just need to be silenced? I ran the build with gcc 4.8.3: $ inplace/mingw/bin/gcc -v Using built-in specs. COLLECT_GCC=C:\msys64\home\Gintas\ghc\inplace\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/msys64/home/Gintas/ghc/inplace/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3 /lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-4.8.3/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with- sysroot=/c/mingw483/x86_64-483-posix-seh-rt_v3-rev0/mingw64 --with-gxx- include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable- languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version- specific-runtime-libs --disable-isl-version-check --disable-cloog-version- check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with- tune=core2 --with-libiconv --with-system-zlib --with- gmp=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpfr=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpc=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- isl=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- cloog=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --enable-cloog- backend=isl --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/lib -L/c/mingw483/prerequisites/x86_64-zlib- static/lib -L/c/mingw483/prerequisites/x86_64-w64-mingw32-static/lib' Thread model: posix gcc version 4.8.3 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10607: Auto derive from top to bottom
by GHC 22 Apr '18

22 Apr '18

#10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: deriving, | Type of failure: None/Unknown typeclass, auto | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It is very good to see that Template Haskell types are now `Generic` and `DeriveAnyClass` have been implemented. I suppose that this auto-deriving thing can go even further. The problem is like the following: When we manipulate a complex composite JSON object, we need to define a dozen of data types for each of the dozen we may need to derive `Eq`, `Show`, `Generic` etc. Another situaition can be manipulating the AST of a language, there may be dozens of data type definitions, also, for each of them, we need to derive `Show`, `Eq`, `Generic`. Take the old Template Haskell types without `Generic` as an example, I want to make them instances of `Generic` type class, I wrote: {{{#!hs deriving instance Generic FixityDirection deriving instance Generic Inline deriving instance Generic RuleBndr deriving instance Generic Match deriving instance Generic Name deriving instance Generic RuleMatch deriving instance Generic Pred deriving instance Generic Phases deriving instance Generic Con deriving instance Generic Module deriving instance Generic AnnTarget deriving instance Generic Type deriving instance Generic TyVarBndr deriving instance Generic TyLit deriving instance Generic Exp deriving instance Generic Lit deriving instance Generic Pat deriving instance Generic Dec deriving instance Generic Clause deriving instance Generic FunDep deriving instance Generic Foreign deriving instance Generic Fixity deriving instance Generic Pragma deriving instance Generic FamFlavour ... }}} How can we use `Generic`? Say we want to serialize Template Haskell data type with `Binary` type class, Of course, by writing `Binary` empty instances or just derive it with `DeriveAnyClass` extension. However, the problem is that we still need to write deriving Binary dozens of times, as many as the trivial `Generic` deriving declaration above. What if GHC can attemp to derive the instance from the top of the tree down to the leaf in the data type declarations? For example: {{{#!hs data Person = Person Names Address | Student Names Address deriving Generic data Names = Names String deriving Generic data Address = Address Gate deriving Generic type Gate = (String,Int) deriving topdown Eq Person }}} It will generate `Eq` instances of `Person`, `Names` and `Address`, since it is in the Person data declaration tree. I tried to implement a prototype see https://github.com/HaskellZhangSong /derive-topdown It is rather an experiment tryout than a formal implementation. If you think this feature is attractive, I would like to discuss it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do
by GHC 20 Apr '18

20 Apr '18

#10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: unicode | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs > isMark '\768' True > isAlphaNum '\768' True > (isAlpha '\768', isNumber '\768') (False,False) }}} This behavior comes from this piece in WCsubst.c: {{{ unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO| GENCAT_MC|GENCAT_ME|GENCAT_MN| GENCAT_NO|GENCAT_ND|GENCAT_NL)) }}} I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++? (And if it's a feature and not a bug, then it should definitely be documented.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11