March 2017 - ghc-tickets

[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] Trac email verification for user: dmm
by GHC 03 Mar '17

03 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=Z0ffZZV7> Username: dmm Verification Token: Z0ffZZV7 -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

03 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 03 Mar '17

03 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

[GHC] #11179: Allow plugins to access "dead code"
by GHC 02 Mar '17

02 Mar '17

#11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- GHC removes dead-bindings quite early in the compilation process, which makes perfect sense from a pure compilation point of view. But with user- plugins, some of the dead-bindings can be interesting: They might be properties or other code that instructs the plugin to do a certain action, even if the binding isn't otherwise used anywhere else or exported. (Think of embedded properties.) Here's a discussion about the issue, where SimonPJ asked for a ticket to be filed: [http://mail.haskell.org/pipermail/ghc- devs/2015-December/010708.html] It appears the desugarer removes some of the dead-code. One option could be to stop the desugarer from doing that, and leaving it to the later optimizer passes so plugins can still see all the bindings (if they run early enough), or require the user to put in an "KeepAlive" pragma on bindings that she cares about. While keeping all-dead code in the desugarer would be the simplest thing to do, requiring the user to put in a pragma isn't a terrible solution either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] Trac email verification for user: ruperthorlick
by GHC 02 Mar '17

02 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=OCnLqZml> Username: ruperthorlick Verification Token: OCnLqZml -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0