February 2019 - ghc-tickets

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 18 Feb '19

18 Feb '19

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics, Deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: deriving-perf, Generics => deriving-perf, Generics, Deriving Comment: Ben, when we emerge from the CI swamp, this ticket looks like one of several GHC-perf tickets that deserve renewed attention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16314: Improve confusing error message with MINIMAL pragma
by GHC 18 Feb '19

18 Feb '19

#16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I got bitten by this recently, and while I can see GHC's reasoning, I wish it told me something different and more useful. {{{#!hs class X a where foo :: a {-# MINIMAL foo #-} foo = undefined instance X Int }}} For this program, ghc says: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘foo’ • In the instance declaration for ‘X Int’ | 7 | instance X Int | ^^^^^ }}} This is arguably "correct", since I made `foo` part of `MINIMAL`; but it's very confusing, because I know I added a default definition. I wish GHC instead said something like: {{{ You made `foo` MINIMAL, but also gave an explicit definition for it. }}} I can see the logic behind the current error message, but it was rather confusing. The background is that my class had many other methods and a `MINIMAL` pragma. Much later I realized I could give a default definition of one of those methods but I forgot to remove it from the `MINIMAL` list. So, I had to puzzle a while at the error messages that were coming from far away modules that had nothing to do with the class definition itself. This is not a showstopper by any means, but unless there are good reasons to do otherwise, it would be nice to get a warning right where the class is defined, as opposed to where it is instantiated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12612: Allow kinds of associated types to depend on earlier associated types
by GHC 18 Feb '19

18 Feb '19

#12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: 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: -------------------------------------+------------------------------------- GHC rejects the following code: {{{#!hs class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a }}} with this error message {{{ • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ }}} See [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-September/026402.html e-mail discussion]. This is connected to #12088, at least as far as defining instances of C. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12218: Implement -fexternal-interpreter via static linking
by GHC 18 Feb '19

18 Feb '19

#12218: Implement -fexternal-interpreter via static linking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- An interesting idea from @hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new iconv binary, and use that as our external interpreter. This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16206: Run Haddock's test suite in CI
by GHC 18 Feb '19

18 Feb '19

#16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.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: -------------------------------------+------------------------------------- Many changes in GHC affect Haddock's output, breaking its test suite. Recent examples are [https://gitlab.haskell.org/ghc/ghc/commit/53874834b779ad0dfbcde6650069c3792… 5387483] and [https://gitlab.haskell.org/ghc/ghc/commit/7cba71fc25af8287db61f6f6aa80d45ce… 7cba71f]. If cases like these were caught during CI, they could be fixed immediately, avoiding follow-up cleanup work by the Haddock maintainer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 17 Feb '19

17 Feb '19

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): See also https://github.com/haskell/cabal/issues/5893 which hits the same issue and makes GHC itself compile slowly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16332: Feature request: Data.Foldable.asumMap
by GHC 17 Feb '19

17 Feb '19

#16332: Feature request: Data.Foldable.asumMap -------------------------------------+------------------------------------- Reporter: josephcsible | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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'd like to request that an `asumMap` function be added to `Data.Foldable`, which would be a generalization of `concatMap` in the same way that `asum` is a generalization of `concat`. Its proposed definition: {{{#!hs asumMap :: (Foldable t, Alternative f) => (a -> f b) -> t a -> f b asumMap f = foldr ((<|>) . f) empty }}} This is almost equivalent to a combination of "asum" and "fmap", but it doesn't require a "Functor t" constraint like that does. Notes on its usefulness: * Here's a Stack Overflow question that asks for a function ((a -> Maybe b) -> [a] -> Maybe b) that this is a more general form of: https://stackoverflow.com/questions/19643664/standard-haskell- function-a-maybe-b-a-maybe-b * The alternative prelude Relude includes this function (although theirs is implemented in terms of foldMap and Alt instead of foldr and <|>): https://hackage.haskell.org/package/relude-0.4.0/docs/Relude-Foldable- Fold.html#v:asumMap * This can also be thought of as a more useful version of `Data.Foldable.find`. For example, if you have a sum type such as `Either` and want to find the value in first one of it that's `Right`, you could do `asumMap rightToMaybe x`. If you were to instead do `find isRight x`, the `Either` won't be unwrapped even though you know it's `Right`, so you'll then have to do something unclean (like a partial function) to get the value out. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family
by GHC 16 Feb '19

16 Feb '19

#14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails to typecheck using the `wip/T2893` branch, to my surprise: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Proxy type family Apply (f :: * -> *) a type instance Apply Proxy a = Proxy a data ExTyFam f where MkExTyFam :: Apply f a -> ExTyFam f instance (forall a. Show (Apply f a)) => Show (ExTyFam f) where show (MkExTyFam x) = show x showsPrec = undefined -- Not defining these leads to the oddities observed in showList = undefined -- https://ghc.haskell.org/trac/ghc/ticket/5927#comment:32 test :: ExTyFam Proxy -> String test = show }}} This fails with: {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:24: error: • Could not deduce (Show (Apply f a)) arising from a use of ‘show’ from the context: forall a. Show (Apply f a) bound by the instance declaration at Bug.hs:16:10-57 • In the expression: show x In an equation for ‘show’: show (MkExTyFam x) = show x In the instance declaration for ‘Show (ExTyFam f)’ | 17 | show (MkExTyFam x) = show x | ^^^^^^ }}} I would have expected the `(forall a. Show (Apply f a))` quantified constraint to kick in, but it didn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #16330: Type inference in presence of pattern matching on GADTs
by GHC 16 Feb '19

16 Feb '19

#16330: Type inference in presence of pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This small example {{{ {-# LANGUAGE GADTs #-} data G a where I :: G Integer f g = case g of I -> () }}} yields {{{ • Couldn't match expected type ‘p’ with actual type ‘()’ ‘p’ is untouchable inside the constraints: a ~ Integer bound by a pattern with constructor: I :: G Integer, in a case alternative at gadtsInference.hs:6:17 ‘p’ is a rigid type variable bound by the inferred type of f :: G a -> p at gadtsInference.hs:6:1-23 Possible fix: add a type signature for ‘f’ • In the expression: () In a case alternative: I -> () In the expression: case g of { I -> () } • Relevant bindings include f :: G a -> p (bound at gadtsInference.hs:6:1) | 6 | f g = case g of I -> () | ^^ }}} Without providing the type annotation for f `f :: G a -> ()` GHC cannot infer the correct result type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16328: NCG: Only adjust al before foreign calls if required.
by GHC 16 Feb '19

16 Feb '19

#16328: NCG: Only adjust al before foreign calls if required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a typical sequence for a foreign call (although newCAF is a RTS function). We zero rax to indicate the number of vector registers used. However this is here (and usually) redundant. {{{ subq $8,%rsp movq %r13,%rax movq %rbx,%rsi movq %rax,%rdi xorl %eax,%eax call newCAF }}} The xor eax, eax here is redundant The System V spec says: > For calls that may call functions that use varargs or stdargs (prototype-less > calls or calls to functions containing ellipsis (...) in the declaration) %al is used > as hidden argument to specify the number of vector registers used. > The contents of %al do not need to match exactly the number of registers, but must be an upper bound on the number of vector registers used and is in the range 0–8 inclusive. This means we can omit the zeroing when we call things like RTS functions or memmov which take a fixed number of arguments at least. On windows this isn't part of the ABI at all so there we can just omit it completely. It's not a huge deal. For nofib/fannkuch-redux these xors are ~0,3% of the size of the .text segment. But it might help with cache in some edge cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0