November 2017 - ghc-tickets

[GHC] #11352: Allow applying type to label
by GHC 02 May '18

02 May '18

#11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE OverloadedLabels #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DataKinds #-} import GHC.TypeLits import GHC.OverloadedLabels instance IsLabel "answer" Int where fromLabel _ = 42 answer :: IsLabel "answer" a => a answer = #answer }}} The follow works: {{{#!hs >>> answer @Int 42 }}} but fails with a label: {{{#!hs >>> #answer @Int <interactive>:...:1: error: • Cannot not apply expression of type ‘t0’ to a visible type argument ‘Int’ • In the expression: #answer @Int In an equation for ‘it’: it = #answer @Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11323: powerpc64: recomp015 fails with redundant linking
by GHC 01 May '18

01 May '18

#11323: powerpc64: recomp015 fails with redundant linking -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time Test Case: | performance bug driver/recomp15 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14149: Tyepchecker generates top-level unboxed coercion
by GHC 27 Apr '18

27 Apr '18

#14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this code {{{ {-# OPTIONS_GHC -fdefer-out-of-scope-variables #-} module Foo where import Data.Coerce f :: Bool f = coerce (k :: Int) }}} It generates a lint error: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_a11N :: (Int :: *) ~R# (Bool :: *)] The type of this binder is unlifted: cobox_a11N Binder's type: (Int :: *) ~R# (Bool :: *) *** Offending Program *** $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Foo"#) cobox_a11N :: (Int :: *) ~R# (Bool :: *) [LclId[CoVarId]] cobox_a11N = typeError @ ('TupleRep '[]) @ ((Int :: *) ~R# (Bool :: *)) "Foo.hs:8:5: error:\n\ \ \\226\\128\\162 Couldn't match representation of type \\226\\128\\152Int\\226\\128\\153 with that of \\226\\128\\152Bool\\226\\128\\153\n\ \ arising from a use of \\226\\128\\152coerce\\226\\128\\153\n\ \ \\226\\128\\162 In the expression: coerce (k :: Int)\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = coerce (k :: Int)\n\ \(deferred type error)"# f :: Bool [LclIdX] f = (typeError @ 'LiftedRep @ Int "Foo.hs:8:13: error: Variable not in scope: k :: Int\n\ \(deferred type error)"#) `cast` (cobox_a11N :: (Int :: *) ~R# (Bool :: *)) *** End of Offense *** }}} Reason: this rather hacky test in `TcUnify.buildImplication` {{{ ; if null skol_tvs && null given && (not deferred_type_errors || not (isTopTcLevel tc_lvl)) }}} did take account of `Opt_DeferOutOfScopeVariables`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14421: LambdaCase should be suggested if it is used but not enabled
by GHC 26 Apr '18

26 Apr '18

#14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If I try to make a multiparameter typeclass GHC (well, GHCi here) advises me to turn on {{{MultiParamTypeClasses}}} {{{ Prelude> class C a b where ... (Use MultiParamTypeClasses to allow multi-parameter classes) }}} But if I try to use {{{\case}}} it doesn't give me a helpful suggestion {{{ Prelude> :t \case (_,_) -> () <interactive>:1:2: error: parse error on input ‘case’ }}} Could it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13520: instance Alternative ZipList
by GHC 26 Apr '18

26 Apr '18

#13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- The paper "From monoids to near-semirings: the essence of MonadPlus and Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)'
by GHC 26 Apr '18

26 Apr '18

#13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- Should {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . pure WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} not use `return`? {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . return WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14200: Deprecate WrappedMonad
by GHC 26 Apr '18

26 Apr '18

#14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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: -------------------------------------+------------------------------------- I believe that `Control.Applicative.WrappedMonad` is obsolete now that AMP is implemented. I would propose deprecating `WrappedMonad` as a result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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