October 2016 - ghc-tickets

[GHC] #11339: Possible type-checker regression in GHC 8.0
by GHC 21 Oct '16

21 Oct '16

#11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: • Couldn't match type ‘f’ with ‘Const [Identity a]’ ‘f’ is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b • In the first argument of ‘t’, namely ‘afb’ In the expression: t afb In a case alternative: _ -> t afb • Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12749: Typechecker regression involving RankNTypes
by GHC 21 Oct '16

21 Oct '16

#12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The following code compiles on GHC 7.0.4 through 7.10.3, but not with GHC 8.0.1, 8.0.2, or HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where type NatTrans f g = forall x. f x -> g x -- NatTrans analog of id applyNT :: NatTrans f g -> NatTrans f g applyNT x = x b :: Bool b = True eitherToMaybe :: NatTrans (Either a) Maybe eitherToMaybe (Left _) = Nothing eitherToMaybe (Right x) = Just x trans :: NatTrans (Either a) Maybe -> NatTrans (Either a) Maybe trans x = x applyNTCheck :: NatTrans (Either a) Maybe applyNTCheck = (if b then trans else applyNT) eitherToMaybe }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:21:27: error: • Couldn't match type ‘NatTrans (Either a) Maybe’ with ‘Either a0 x0 -> Maybe x0’ Expected type: (Either a0 x0 -> Maybe x0) -> Either a x -> Maybe x Actual type: NatTrans (Either a) Maybe -> Either a x -> Maybe x • In the expression: trans In the expression: if b then trans else applyNT In the expression: (if b then trans else applyNT) eitherToMaybe • Relevant bindings include applyNTCheck :: Either a x -> Maybe x (bound at Bug.hs:21:1) }}} (Originally spotted [https://github.com/ku-fpg/natural- transformation/pull/13#issuecomment-255378141 here].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12743: Profiling wrongly attributes allocations to a function with Int# result
by GHC 20 Oct '16

20 Oct '16

#12743: Profiling wrongly attributes allocations to a function with Int# result -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Profiling can't decide whether the given function allocates or not at all. The code snippet says it all: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts -- ghc -prof --make bork.hs -fprof-auto -O1 -- ./bork +RTS -s -P -RTS main = do let f :: Int -> Int# -- {-# NOINLINE f #-} f x = case x `div` 17 of I# i -> i -- {-# NOINLINE g #-} g h = sum $ map (\y -> I# (h y)) [0..1000000] g f `seq` return () -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 73.6 93.3 159 224000328 -- main.f Main 24.1 6.7 52 16000016 -- main.g.\ Main 2.3 0.0 5 0 -- When either of the NOINLINE is enabled, the profile becomes: -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 72.9 93.3 161 224000328 -- main.f Main 16.7 0.0 37 0 -- main.g.\ Main 10.4 6.7 23 16000016 -- So, does f actually allocate or not? -- Profiling is quite a bit less useful if it can't answer that reliably, -- because in larger code snippets it's hard to decide from source -- or from Core/STG. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb
by GHC 20 Oct '16

20 Oct '16

#12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ----------------------------------------+--------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #11627 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Reproducible with 7.10.3, 8.0.1 and today's HEAD ( afa6e8309e8e7a069abcf7879791d53cdf22f00a). The test was added by @jme in #11627. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems
by GHC 19 Oct '16

19 Oct '16

#12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems -------------------------------------+------------------------------------- Reporter: gliptak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I downloaded http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-x86_64-deb8-linux.tar.xz and running configure on Alpine Linux (musl based) failed. The immediate cause seems to be that ghc-* files are not linked statically. {{{ /tmp/ghc-8.0.1 # file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6359ffd9a860387d6f91c40dccceaddd493f7a54, not stripped /tmp/ghc-8.0.1 # file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9fcf1bc38db049d6bafc6e611c09b6700071bfbb, not stripped }}} Could static linkage be considered for these helpers allowing them to run on non-glibc setups? Thanks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope
by GHC 19 Oct '16

19 Oct '16

#12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I recently wrote this: {{{ {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE TypeApplications #-} module B where f :: forall a. a -> a f x = id @a x }}} And was hornswoggled for the better part of five minutes for why "a" wasn't in scope. Answer: you need `ScopedTypeVariables`. A suggestion would be nice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12140: Clarify Trac menus for new reporters
by GHC 18 Oct '16

18 Oct '16

#12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 officemate of mine rarely posts bugs here. He finds the interface to posting a bug confusing. I have to say I agree, if I consider the perspective of an infrequent reporter. (The reason he rarely posts bugs is that he rarely has bugs to post, not because of the confusing interface.) Specifically, there are many fields to fill out when posting a bug. Some of these are important to us (`Version` probably being the most). Some are better for developers to set (`Milestone`, `Test case`). Some are less important (`Operating System` for a bug in the type-checker). Some are essentially ignored (`Type of failure`, in my experience). Yet a new reporter doesn't know any of this and will diligently try to fill out them all. Can we label the fields as to importance somehow? Mark some as advanced/dev only? Make some available only after posting the ticket (`Test case`, `Differential`)? I don't suppose there are masses of people out there trying to post bugs and stymied by this problem, but I do think we can clean this up a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12733: Orphan hashes are not being propagated correctly
by GHC 18 Oct '16

18 Oct '16

#12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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 Phab:D2607, simonpj asked why we didn't also put class instances in the export hash. Why indeed. In the course of investigating, I discovered another bug in how we handle orphan recompilation. Unfortunately, this bug needs two packages to manifest. {{{ -- p/P.hs module P where instance Show (a -> b) where --instance Show (IO a) where -- q/Q.hs module Q where import P -- q/Q2.hs module Q2 where import Q }}} Put in some default Cabal files, with q depending on p, and then build the entire kaboodle. Then edit `p/P.hs` to uncomment the second orphan instance. Rebuild. {{{ ezyang@sabre:~/Dev/labs/orph$ cabal new-build q -w ghc-head In order, the following will be built (use -v for more details): - p-0.1.0.0 (lib) (file P.hs changed) - q-0.1.0.0 (lib) (dependency rebuilt) Preprocessing library p-0.1.0.0... [1 of 1] Compiling P ( P.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/p-0.1.0.0/build/P.o ) P.hs:2:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (a -> b)’ P.hs:3:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (IO a)’ module Q2 where Preprocessing library q-0.1.0.0... [1 of 2] Compiling Q ( Q.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/q-0.1.0.0/build/Q.o ) [P changed] ezyang@sabre:~/Dev/labs/orph$ }}} Notice: Q2 never got rebuilt. This is wrong wrong wrong: P changed, and we need to rebuild Q2! Here are the hashes for Q.hi before and after: {{{ -- Before interface Q 80120161016 interface hash: 2ffc06a1552565a73c888110ab4cf8df ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 -- After interface Q 80120161016 interface hash: 009db9e5ecbe49e36b7bf38e02087e75 ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 }}} The orphan hash didn't get updated. At the moment, when we compute the orphan hash, we only consider the orphan hashes from the home package. Here's the comment justifying it: {{{ -- the export hash of a module depends on the orphan hashes of the -- orphan modules below us in the dependency tree. This is the way -- that changes in orphans get propagated all the way up the -- dependency tree. We only care about orphan modules in the current -- package, because changes to orphans outside this package will be -- tracked by the usage on the ABI hash of package modules that we import. }}} It is true that we know to rebuild Q.hs when P.hs changes. But that is not much solace for Q2.hs... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12411: GHC panic on TypeApplications + TemplateHaskell
by GHC 18 Oct '16

18 Oct '16

#12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications, TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails {{{ $ ghci -XTemplateHaskell -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import Control.Lens Prelude Control.Lens> data A = B { _int :: Int } Prelude Control.Lens> pure @Q []; makeLenses ''A ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tcMonoExpr _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Control.Lens> }}} sorry, don't have time for more detail -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings
by GHC 18 Oct '16

18 Oct '16

#12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple rebindablesyntax | overloadedstrings deriving show | string | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using both `RebindableSyntax` and `OverloadedStrings`, `deriving (Show)` no longer works. Example program: {{{#!hs {-# LANGUAGE RebindableSyntax, OverloadedStrings #-} module Bug where import Prelude (String,Show(..)) newtype Text = Text String fromString :: String -> Text fromString = Text x :: Text x = "x" newtype Foo = Foo () deriving (Show) }}} In this example, `fromString` is redefined to return a type different from `[Char]`. The example `x` typechecks due to to the `RebindableSyntax` and `OverloadedStrings` extensions. However, the generated code for the `deriving (Show)` instance for Foo does not typecheck, and ghc gives a code generation error: {{{#!hs error: • Couldn't match type ‘Text’ with ‘[GHC.Types.Char]’ Expected type: String Actual type: Text • In the first argument of ‘GHC.Show.showString’, namely ‘"Foo "’ In the first argument of ‘(GHC.Base..)’, namely ‘(GHC.Show.showString "Foo ")’ In the second argument of ‘GHC.Show.showParen’, namely ‘((GHC.Base..) (GHC.Show.showString "Foo ") (showsPrec 11 b1))’ When typechecking the code for ‘showsPrec’ in a derived instance for ‘Show Foo’: To see the code I am typechecking, use -ddump-deriv }}} A solution would be to protect the code generated by `deriving (Show)` from `OverloadedStrings` and `RebindableSyntax` extensions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7