February 2017 - ghc-tickets

[GHC] #12156: -fdefer-typed-holes causes panic on unbound variable
by GHC 06 May '17

06 May '17

#12156: -fdefer-typed-holes causes panic on unbound variable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- {{{#!haskell module Main where main = do print v return () }}} Compile it without {{{-fdefer-typed-holes}}} and it fails as expected: {{{ ➜ hole_bug ghc --make Main.hs -fforce-recomp [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:4:11: error: Variable not in scope: v }}} Adding {{{-fdefer-typed-holes}}} is causing a panic instead of runtime error: {{{ ➜ hole_bug ghc --make Main.hs -fforce-recomp -fdefer-typed-holes [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:4:11: warning: [-Wtyped-holes] Variable not in scope: v ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dShow_aKo local binds for: $trModule $trModule1_r16k $trModule2_r16s sat_s16x sat_s16z Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Tried with: 8.0.1, HEAD as of today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9557: Deriving instances is slow
by GHC 06 May '17

06 May '17

#9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's take [https://raw.githubusercontent.com/haskell-suite/haskell-src- exts/8e0153d33b66add96fd5606614ce7938d2029510/src/Language/Haskell/Exts/Annotated/Syntax.hs this file] (from haskell-src-exts) and build it with -O0. On my machine it takes 55s. If we remove deriving of all classes except Functor (which is the only one used by the module itself), the time will drop down to 4s. Different classes vary in their compile-time cost, but there's no single culprit. Among the costly ones are Generic, Data, Show, Ord. haskell-src-exts users are very annoyed by its long compile time, about 10 minutes, especially because we don't compile with -O0 by default. It would be nice to get this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11799: Legend for hpc markup colors
by GHC 05 May '17

05 May '17

#11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- The hpc markup colors are not documented anywhere. Coming from an imperative background, red means never executed and green means executed at least once. Here, green means always true, red means always false, yellow means never executed. Adding a one-line legend at the top of the output file(s) describing the colours would help a lot. Suggesting `never executed` `always true` and `always false` on a single line at the top with the same yellow, green and red background as the respective highlighted code would have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11616: Kinds aren't instantiated
by GHC 05 May '17

05 May '17

#11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType, AllowAmbiugousTypes #-} class Whoami a where whoami :: String instance Whoami Int where whoami = "int" instance Whoami Bool where whoami = "[y/n]" instance Whoami Maybe where whoami = "call me maybe" }}} we can write {{{ >>> whoami @Type @Int "int" >>> whoami @Type @Bool "[y/n]" >>> whoami @(Type -> Type) @Maybe "call me maybe" }}} Attempting to specialise `whoami` to `Type` we can't simply write `whoamiType = whoami @Type` as one might expect. To start we define a synonym: {{{ $ ghci -ignore-dot-ghci /tmp/t17q.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/t17q.hs, interpreted ) Ok, modules loaded: Main. *Main> whoami2 = whoami <interactive>:1:1: error: • Ambiguous type variable ‘a0’ arising from a use of ‘whoami’ prevents the constraint ‘(Whoami a0)’ from being solved. Probable fix: use a type annotation to specify what ‘k0’, ‘a0’ should be. These potential instances exist: three instance involving out-of-scope typess (use -fprint-potential-instances to see them all) • When instantiating ‘whoami2’, initially inferred to have this overly-general type: forall k (a :: k). Whoami a => String NB: This instantiation can be caused by the monomorphism restriction. }}} Using the “overly-general” inferred type `whoami :: forall k (a :: k). Whoami a => String` fails: {{{#!hs -- • Could not deduce (Whoami a0) arising from a use of ‘whoami’ -- from the context: Whoami a -- bound by the type signature for: -- whoami2 :: Whoami a => String -- at /tmp/t17q.hs:20:1-44 -- The type variable ‘a0’ is ambiguous -- These potential instances exist: -- three instance involving out-of-scope typess -- (use -fprint-potential-instances to see them all) -- • In the expression: whoami -- In an equation for ‘whoami2’: whoami2 = whoami whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami }}} so we need `TypeApplications`: {{{#!hs whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami @_ @a }}} and then we can write: {{{#!hs whoamiType :: forall (a :: Type). Whoami a => String whoamiType = whoami @_ @a }}} and we can write as intended: {{{ >>> whoamiType @Int "int" >>> whoamiType @Bool "[y/n]" }}} Is there a reason one cannot write: {{{#!hs whoami2 = whoami whoamiType = whoami @Type }}} ---- As a side note, what is the difference between {{{#!hs -- >>> :set -fprintf-explicit-foralls -- >>> :kind Whoami1 -- Whoami1 :: forall {k}. k -> Constraint -- >>> :kind Whoami2 -- Whoami2 :: forall k. k -> Constraint class Whoami1 a class Whoami2 (a :: k) }}} Is there a snippet of code that highlights differences -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances)
by GHC 05 May '17

05 May '17

#13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableInstances loop | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm afraid this will simply be seen as "that's what happens when you use UndecidableInstances", but I might as well document this issue I had. Trying to play with a "Trees that Grow" syntax, I encountered an issue when making a mistake, that can be boiled down to the following: {{{#!hs {-# language ConstraintKinds, FlexibleContexts, TypeFamilies, UndecidableInstances #-} module Loop where import GHC.Exts (Constraint) import Test.QuickCheck type family X_Var ξ data TermX ξ = Var (X_Var ξ) type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) ) --genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ) genTerm 0 = Var <$> arbitrary genTerm n = Var <$> genTerm (n - 1) --instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where --arbitrary = sized genTerm }}} This code will compile correctly, and generate: {{{#!hs genTerm :: (X_Var ξ ~ TermX ξ, Arbitrary (TermX ξ), Eq t, Num t) => t -> Gen (TermX ξ) }}} Which is correct (though, not the type I had intended, since my code had a mistake). Now, if you uncomment the "instance" line only, the compiler will loop. Adding the commented out type, of course, gives a type error where it's due. I was just wondering whether this type of error failed with the loops that should be caught by the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11333: GHCi does not discharge satisfied constraints
by GHC 03 May '17

03 May '17

#11333: GHCi does not discharge satisfied constraints ----------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- Don't know if this is the intended behaviour (GHCi, version 8.1.20151231), with the new extension TypeApplications. For the function [https://hackage.haskell.org/package/base-4.8.1.0/docs /Text-Show.html#v:show show]: {{{#!hs Prelude> :set -XTypeApplications Prelude> :t show show :: Show a => a -> String Prelude> :t show @Int show @Int :: Show Int => Int -> String }}} And the function [https://hackage.haskell.org/package/base/docs/Data- Typeable.html#v:eqT eqT] (`:: forall a b. (Typeable a, Typeable b) => Maybe (a :~: b)`): {{{#!hs Prelude> :set -XTypeApplications Prelude> import Data.Typeable Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT @Int eqT @Int :: (Typeable Int, Typeable b) => Maybe (Int :~: b) }}} Should the types of `show @Int` and `eqT @Int` not be `Int -> String` and `(Typeable b) => Maybe (Int :~: b)` respectively? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13333: Typeable regression in GHC HEAD
by GHC 03 May '17

03 May '17

#13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently wrote some code while exploring a fix for #13327 that heavily uses poly-kinded `Typeable`. This compiles without issue on GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module DataCast where import Data.Data import GHC.Exts (Constraint) data T (phantom :: k) = T data D (p :: k -> Constraint) (x :: j) where D :: forall (p :: k -> Constraint) (x :: k). p x => D p x class Possibly p x where possibly :: proxy1 p -> proxy2 x -> Maybe (D p x) dataCast1T :: forall k c t (phantom :: k). (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) dataCast1T f = case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f }}} But on GHC HEAD, it barfs this error: {{{ Bug.hs:28:29: error: • Could not deduce (Typeable T) arising from a use of ‘gcast1’ GHC can't yet do polykinded Typeable (T :: * -> *) from the context: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) bound by the type signature for: dataCast1T :: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) at Bug.hs:(22,1)-(25,35) or from: (k ~ *, (phantom :: k) ~~ (x :: *), Data x) bound by a pattern with constructor: D :: forall k (p :: k -> Constraint) (x :: k). p x => D p x, in a case alternative at Bug.hs:28:23 • In the expression: gcast1 f In a case alternative: Just D -> gcast1 f In the expression: case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f | 28 | Just D -> gcast1 f | ^^^^^^^^ }}} That error message itself is hilariously strange, since GHC certainly has the power to do polykinded `Typeable` nowadays. Marking as high priority since this is a regression—feel free to lower the priority if you disagree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int"
by GHC 03 May '17

03 May '17

#11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{ baldur@Loki:~$ ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> let foo :: forall a. Eq a. Int; foo = undefined <interactive>:1:20: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Prelude> :set -XRankNTypes Prelude> let foo :: forall a. Eq a. Int; foo = undefined <interactive>:3:26: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Prelude> }}} also {{{ Prelude> :kind forall a. Eq a. Int <interactive>:1: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> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10230: multiline literals doesn't work with CPP extension.
by GHC 02 May '17

02 May '17

#10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If LANGUAGE CPP is enabled then multiline literals stops working. Steps to reproduce. 1. write a program with multiline literal: cat 1.hs {{{#!hs test = "mutli\ \line" main = putStrLn test }}} 2. it should compile without CPP: ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... 3. compile it with CPP extension Expected result: program compiles {{{ ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... }}} Actual result: compilation breaks {{{ ghc -XCPP 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) [flags changed] 1.hs:1:18: lexical error in string/character literal at character 'l' }}} At least ghc-7.8.4 and ghc-7.10 are affected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5