September 2018 - ghc-tickets

[GHC] #10859: Generated Eq instance associates && wrongly
by GHC 18 Sep '18

18 Sep '18

#10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 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: #10858 Differential Revisions: | -------------------------------------+------------------------------------- Currently, we derive this code for `(==)`: {{{ (==) (ImportDecl a1_acXi a2_acXj a3_acXk a4_acXl a5_acXm a6_acXn a7_acXo a8_acXp) (ImportDecl b1_acXq b2_acXr b3_acXs b4_acXt b5_acXu b6_acXv b7_acXw b8_acXx) = (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr))) && ((a3_acXk == b3_acXs))) && ((a4_acXl == b4_acXt))) && ((a5_acXm == b5_acXu))) && ((a6_acXn == b6_acXv))) && ((a7_acXo == b7_acXw))) && ((a8_acXp == b8_acXx))) }}} To me this looks wrongly associated: Since `&&` is strict in the left but lazy in the right argument, shouldn’t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away? The culprit is this line: {{{ = foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs) }}} and I was just about to change that ot `foldr1`, but then I did some git- archeology and found that Simon changed that deliberately from `foldr1` to `foldl1` in changeset:8de16184643ea3c2f9f30b5eaed18db6ef247760. Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15510: Qualified Holes
by GHC 18 Sep '18

18 Sep '18

#15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Let us consider the following example code: {{{ import qualified Data.Map as M main :: IO () main = print (M._ (\k v acc -> k + v + acc) 0 myMap) myMap :: Map Int Int myMap = ... }}} This errors with `Not in scope: M._`. It would cool if GHC instead treated `M._` as a hole but only gave suggestions from the module `Data.Map`. So, in this case, it would suggest things like `Data.Map.foldrWithKey` and `Data.Map.foldlWithKey`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15642: Improve the worst case performance of weak pointers
by GHC 18 Sep '18

18 Sep '18

#15642: Improve the worst case performance of weak pointers -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.6.1-beta1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Garbage collecting weak pointers involves repeatedly traversing the weak pointer list, checking which keys are still alive, and in response marking the relevant values and finalizers live. This works well in most cases, but if there are long chains of weak pointers, it's terrible. I wonder if we can do something about that without significantly hurting performance elsewhere. Here's the (probably naive) idea: 1. Maintain a hash table mapping weak pointer keys to lists of weak pointers. This replaces the current weak pointer list. 2. Use a bit in the info table pointer of every heap object to indicate whether that object is referenced from any `Weak#`. This is the weakest link: if we don't have a spare bit there, or don't want to use one, then I think this whole idea is sunk. When creating a weak pointer, set the appropriate bit in the key and insert the key and pointer into the hash table. When performing early finalization, clear the bit in the key if no other `Weak#` points to it. When performing garbage collection: check the bit in each object as it is marked. If the bit is set, move the key and its attached `Weak#`s from the hash table into a new hash table (or an association list that gets turned into a hash table after evacuation or whatever), and mark all the linked weak pointer targets and finalizers live. In the end, the old hash table contains only unreachable objects. Now mark those objects live (for finalization and in case of resurrection), and queue up the finalizers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15208: GHC 8.4 fails to build on Debian armel (softfloat)
by GHC 17 Sep '18

17 Sep '18

#15208: GHC 8.4 fails to build on Debian armel (softfloat) --------------------------------+--------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- This seems intentional but on the other hand the error message says "Please report this as a GHC bug" {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/Updates.cmm -o rts/dist/build/Updates.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 make[3]: *** Waiting for unfinished jobs.... ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Updates.o' failed make[3]: *** [rts/dist/build/Updates.o] Error 1 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/PrimOps.o' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.4.3-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13617: Segfault in Windows GHCi involving C code compiled with -O4
by GHC 17 Sep '18

17 Sep '18

#13617: Segfault in Windows GHCi involving C code compiled with -O4 ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following: {{{ $ git clone https://github.com/RyanGlScott/hmatrix-segfault $ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5 $ cd hmatrix-segfault/ $ cabal install $ runghc exe/Main.hs Access violation in generated code when reading ffffffffffffffff }}} Running `Main.hs` in GHCi crashes, whereas compiling it works: {{{ $ ghc exe/Main.hs $ ./exe/Main.exe [1,1,1,1,1,1,1,1,1,1,1,1] }}} I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1. There are a couple of things that appear to be necessary to trigger the segfault: 1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`. 2. You need to define the [https://github.com/RyanGlScott/hmatrix- segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype. Removing either of these things causes the program to work again under GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15638: Make Ptr argument to hGetBuf and hGetBufSome strict
by GHC 17 Sep '18

17 Sep '18

#15638: Make Ptr argument to hGetBuf and hGetBufSome strict -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Currently, we have: {{{ hGetBufSome :: Handle -> Ptr a -> Int -> IO Int hGetBufSome h ptr count = ... hGetBuf :: Handle -> Ptr a -> Int -> IO Int hGetBuf h ptr count }}} I propose putting a bang pattern on the `ptr` argument to both of these functions. Currently, the non-strictness of this argument causes it to be boxed by functions that call it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15650: Add (or document if already exist) ability to derive custom typeclasses via source plugins
by GHC 17 Sep '18

17 Sep '18

#15650: Add (or document if already exist) ability to derive custom typeclasses via source plugins -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: source | Operating System: Unknown/Multiple plugins,deriving,typeclass | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem Suppose, I have some custom typeclass `Foo` defined in some library `foo`: {{{#!hs class Foo a where ... some methods ... }}} I would like to be able to derive instances of this typeclass for any possible data type using `deriving` clause just like GHC already does for typeclasses `Eq`, `Ord`, `Show`, `Read`, `Enum`, etc.: {{{#!hs data Bar = Bar | Baz deriving (Eq, Ord, Foo) }}} There're already two possible ways to derive instances of custom typeclasses: 1. `anyclass` deriving strategy (usually involves `Generic`) 2. `-XTemplateHaskell` solution. But I would like to have source-plugin-based solution for this problem so I can just add `-fplugin=Foo.Plugin` and enjoy deriving capabilities. == Advantage over existing approaches Solution with `-XTemplateHaskell` is not that pleasant to write and easy to maintain (you need to use libraries like http://hackage.haskell.org/package/th-abstraction to support multiple GHC versions),involves scoping restriction and is syntactically uglier. Compare: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Bar = Bar | Baz deriving (Eq, Ord) deriveFoo ''Bar }}} Solution with something like `Generic` introduces performance overhead (required for to/from generic representation conversion). This might not be significant for something like ''parsing CLI arguments'' but it's more important if you want to have efficient binary serialisation. Also, it's known that deriving typeclasses is a relatively slow compilation process (https://github.com/tfausak/tfausak.github.io/issues/127) so there's slight chance that deriving typeclass manually can be slightly faster than deriving `Generic + MyClass`. Especially when maintainers of plugins can experiment with some caching strategies for deriving typeclasses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods
by GHC 17 Sep '18

17 Sep '18

#12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- It is unfortunate that if we want to (efficiently) derive a new type class then we have to bake the derivation logic into GHC itself. It seems desirable to be able to implement new deriving methods in libraries in some manner. Ryan Scott says: > I think this would be a wonderful thing to have. Matthew Pickering > (cc'd) has expressed a desire to have all the logic for the `bespoke` > deriving strategies compartmentalized into a library that could easily > be expanded on in the future to support more typeclasses in base. > (Bifunctor, anyone?) > > Unfortunately, each of the major players in today's Haskell > metaprogramming scene that I'm aware of have some downfalls that make > them unsuitable as `deriving` replacements: > > * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword > * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. > * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. > > The way I see it, the whole `deriving` business as it currently stands > today is a somewhat-grotesque-but-darn-useful hack that gets around > the lack of a truly nice metaprogramming facility in Haskell. I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Until then, > -XDerivingStrategies provides a way to contain some of the madness of > `deriving` after having many features tacked onto it in recent GHC > releases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4017: Unhelpful error message in GHCi
by GHC 16 Sep '18

16 Sep '18

#4017: Unhelpful error message in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.12.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13862 | Differential Rev(s): Phab:D5122 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed Comment: I think this is fixed with Phab:D5122. Please re-open if you disagree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4017#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13862: Optional "-v" not allowed with :load in GHCi
by GHC 16 Sep '18

16 Sep '18

#13862: Optional "-v" not allowed with :load in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When loading a file in GHCi with the command {{{:load}}} and the file must import another file, if that other file is unavailable then GHCi sends the following error\\ {{{ Failed to load interface for `xxx` Use -v to see a list of the files searched for. }}} ' xxx ' is the name of the imported file that GHCi cannot find.\\ But we can not use a flag ( ie -v) with the command {{{:load}}} in GHCi.\\ This error is not appropriate in GHCi when using {{{:load}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10