February 2017 - ghc-tickets

[GHC] #10830: maximumBy has a space leak
by GHC 04 Mar '17

04 Mar '17

#10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the program: {{{#!hs import Data.List main = print $ maximumBy compare [1..10000] }}} Compiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get: {{{ $ ghc --make Test.hs -O2 -rtsopts [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... $ Test +RTS -K100K Stack space overflow: current size 33680 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did. See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13353: foldr/nil rule not applied consistently
by GHC 04 Mar '17

04 Mar '17

#13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just had a project where it made a difference whether I add {{{ {-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-} }}} to my file or not, despite this rule already being present in the library. I tried to minimize the problem and came up with this: {{{#!hs foo1 (f, fs) (x, xs) = (f x, map ($x) fs ++ map f xs) foo2 f fs x xs = (f x, map ($x) fs ++ map f xs) test1 x xs = foo1 (id, []) (x, xs) test2 x xs = foo2 id [] x xs test3 x xs = (id x, map ($x) [] ++ map id xs) }}} `test2` and `test3` nicely optimize the `map … [] ++` away, but `test` does not. (In this minimized example, adding the rule again locally does *not* help, but there is still something fishy.) Also, in all cases, `map id` remains, which should not be the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure
by GHC 03 Mar '17

03 Mar '17

#11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See attached file. I think both type signatures for xs should work. The ghci error unfortunately doesn't show up on :reload, but it shows up when trying to run an unrelated function (main here). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13340: Core top-level bindings no longer deduplicated
by GHC 03 Mar '17

03 Mar '17

#13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This module {{{#!hs module Two where f :: Int -> Int f n = n + 1 + 1 g :: Int -> Int g n = n + 1 + 1 }}} used to (in 8.0) optimize to a definition of `g` plus `f = g`. The Common sub-expression phase noticed `f` and `g` were equal. That doesn't happen any more in HEAD and we end up with two copies of the code. The Common sub-expression pass apparently still runs, it just doesn't succeed in removing one of the bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary
by GHC 03 Mar '17

03 Mar '17

#12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ -- Y.hs-boot {-# LANGUAGE ScopedTypeVariables #-} module Y where f :: forall a b. (a, b) -- YY.hs module YY where import {-# SOURCE #-} Y -- Y.hs {-# LANGUAGE ScopedTypeVariables #-} module Y where import YY f :: forall b a. (a, b) f = undefined }}} I get the following unhelpful error: {{{ ezyang@sabre:~$ ghc-8.0 --make Y.hs -fforce-recomp [1 of 3] Compiling Y[boot] ( Y.hs-boot, Y.o-boot ) [2 of 3] Compiling YY ( YY.hs, YY.o ) [3 of 3] Compiling Y ( Y.hs, Y.o ) Y.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: (a, b) Boot file: f :: (a, b) The two types are different }}} Yes this example is purposely shooting itself in the foot, but in the wild I encountered an un-annotated type which inferred a different quantifier ordering than what I expected, and I subsequently spent a while puzzling over the error message. `-fprint-explicit-foralls` is a sufficient workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12429: Pattern synonym parse error should recommend enabling extension
by GHC 02 Mar '17

02 Mar '17

#12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: pattern | Operating System: Unknown/Multiple synonym error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example: {{{#!hs module X where import Data.Text (pattern Y) x = 3 }}} Yields, when compiled on GHC 7.10, {{{ test.hs:3:27: parse error on input "Y" }}} It would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12811: GHC tells me to use RankNTypes when it's already enabled
by GHC 02 Mar '17

02 Mar '17

#12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where foo :: foral a. a -> a foo x = x }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:15: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} That is, the real culprit was misspelling `forall` as `foral`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13347: Abstract classes in hs-boot should not be treated as injective
by GHC 02 Mar '17

02 Mar '17

#13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- They could be implemented by a newtype (see `mkClass`), making them non- injective. Fortunately, this doesn't seem to cause any unsoundness, because the *constructor* for the newtype corresponding to a class is never in scope, so we are never allowed to unwrap "class newtypes". Phew! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13290: Data constructors should not have RULES
by GHC 02 Mar '17

02 Mar '17

#13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- GHC has never (knowingly) supported rules for data constructors, like {{{ {-# RULES "BadBadBad" Just [x,y] = Just [] #-} Notice that the rule is for the ''constructor itself''. Presumably the intent is that any occurrence of `Just` appplied to a two-element list will rewrite to `Just []`. But currently they are accidentally allowed through, and then behave in mysterious ways because of constructor wrappers. Duncan Coutts says {{{ > Well I've certainly tried to use that in the past. > A previous version of the cbor lib which used a different > representation did a lot of matching on constructors to re-arrange > input to an interpreter, until I discovered that GHC actually uses > constructor wrappers and that matching on constructors was thus not > reliable }}} I think we should simply make it illegal for now. If you really want it, use a smart constructor thus {{{ mkJust x = Just x {-# INLINE [0] mkJust #-} {-# RULES “Good” mkJust [x,y] = mkJust [] #-} }}} So let us * Check in that you don't try to write a rule for a data constructor. * Document in the user manual -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13102: orphan family instances can leak through the EPS in --make mode
by GHC 02 Mar '17

02 Mar '17

#13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- In --make mode there is a single EPS whose `eps_fam_inst_env` holds all type family instances that have been read from interface files from external packages for any reason. The type checker uses this field pervasively via `tcGetFamInstEnvs`. When compiling multiple files it's fairly easy to set up a situation in which 1. the first module to be compiled `A` loads an interface file `O.hi` from another package containing an orphan family instance (say, because it imports the module directly); 2. a later module `B` uses this instance to reduce a type, even though `B` has no dependency at all on the module `O` defining the instance. (The only tricky bit in arranging this is that since `B` cannot depend on `A`, a little good fortune is needed for GHC to decide to compile `B` after `A`.) Now another module could import `B` and obtain a function whose definition relies on a type family instance that is not visible from `B` at all, compromising type safety. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22