February 2017 - ghc-tickets

[GHC] Trac email verification for user: Saish
by GHC 21 Feb '17

21 Feb '17

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

1 0

[GHC] #12636: ProfHeap's printf modifiers are incorrect
by GHC 21 Feb '17

21 Feb '17

#12636: ProfHeap's printf modifiers are incorrect ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: newcomer | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- during compile I noticed {{{ rts\ProfHeap.c: In function 'dumpCensus': rts\ProfHeap.c:768:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "VOID\t%lu\n", ^ rts\ProfHeap.c:770:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "LAG\t%lu\n", ^ rts\ProfHeap.c:772:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "USE\t%lu\n", ^ rts\ProfHeap.c:774:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "INHERENT_USE\t%lu\n", ^ rts\ProfHeap.c:776:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "DRAG\t%lu\n", ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13281: Linting join points
by GHC 21 Feb '17

21 Feb '17

#13281: Linting join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Core Lint should check the polymorphic invariant on join points. See (4) in `Note [Invariants on join point]` in `CoreSyn`, and `chekValidJoinPointType`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13297: Panic when deriving Applicative instance through transformer
by GHC 21 Feb '17

21 Feb '17

#13297: Panic when deriving Applicative instance through transformer -------------------------------------+------------------------------------- Reporter: blaze | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if code below is valid, but panic is wrong anyway. {{{#!hs {-# Language TypeFamilies, StandaloneDeriving, GeneralizedNewtypeDeriving, UndecidableInstances #-} module Example where newtype N p m a = N (((CT p) m) a) deriving instance (CT p ~ f, Functor (f m)) => Functor (N p m) deriving instance (CT p ~ f, Applicative (f m)) => Applicative (N p m) -- panic when this line added class C p where type CT p :: (* -> *) -> * -> * }}} Compiler output for 8.0.1 and 8.0.2 is slightly different: {{{ test.hs:6:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: f1_auk[sk] }}} {{{ test.hs:6:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: f1_aun[sk] }}} If I try to derive only Functor instance, code compiles just fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13255: aws package fails to build with master
by GHC 21 Feb '17

21 Feb '17

#13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `aws` package from Hackage fails to build with `master`, {{{ [22 of 76] Compiling Aws.DynamoDb.Core ( Aws/DynamoDb/Core.hs, /home/ben/code/mediawiki-annotate/dist- newstyle/build/x86_64-linux/ghc-8.1.20170209/aws-0.14.1/build/Aws/DynamoDb/Core.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170209 for x86_64-unknown-linux): completeCall $wloop_length_s18Cv Stop[BoringCtxt] Int# -> Int# -> Int Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1598:9 in ghc:Simplify Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13264: GHC panic with (->) generalization branch while compiling lens
by GHC 20 Feb '17

20 Feb '17

#13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- While testing characterizing the performance impact of the Typeable branch (`wip/ttypeable`) against Hackage packages I have found that `lens` manages to break the `(->)` kind-generalization patch. Specifically, `TcCanonical.can_eq_nc` induces a panic by `tcRepSplitTyApp_maybe` during compilation of `Control.Lens.Traversal.holesOf`, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170207 for x86_64-unknown-linux): tcRepSplitTyConApp_maybe ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] c_alzb[tau:5] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1456:5 in ghc:TcType tcRepSplitTyConApp_maybe, called at compiler/typecheck/TcCanonical.hs:617:25 in ghc:TcCanonical }}} The last thing emitted by tc-trace is, {{{ can_eq_nc False [WD] hole{alyP} {0}:: (p_alyn[tau:5] :: TYPE p_alym[tau:5]) GHC.Prim.~# (cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] :: *) nominal equality ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] -> c_alzb[tau:5] p_alyn[tau:5] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] }}} While I haven't yet fully reduced the reproducer to a standalone module, replacing `Control.Lens.Traversal` in a `lens` working tree is sufficient, {{{#!hs {-# LANGUAGE Rank2Types #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Control.Lens.Traversal where import Control.Category import Control.Lens.Internal.Bazaar import Control.Lens.Internal.Context import Control.Lens.Internal.Indexed import Data.Tagged import Prelude hiding ((.),id) type Over p f s t a b = p a (f b) -> s -> f t holesOf :: forall p s t a. Conjoined p => Over p (Bazaar p a a) s t a a -> s -> [Pretext p a a t] holesOf l s = unTagged ( conjoined (Tagged $ let f [] _ = [] f (x:xs) g = Pretext (\xfy -> g . (:xs) <$> xfy x) : f xs (g . (x:)) in f (ins b) (unsafeOuts b)) (Tagged $ let f [] _ = [] f (wx:xs) g = Pretext (\wxfy -> g . (:Prelude.map extract xs) <$> cosieve wxfy wx) : f xs (g . (extract wx:)) in f (pins b) (unsafeOuts b)) :: Tagged (p a b) [Pretext p a a t] ) where b = l sell s }}} More specifically, {{{ $ git clone git://github.com/bgamari/hashable $ git clone git://github.com/ekmett/comonad $ git clone git://github.com/ekmett/semigroupoids $ git clone git://github.com/ekmett/lens $ cabal install ./comonad ./lens ./semigroupoids ./hashable --with- ghc=`pwd`/inplace/bin/ghc-stage2 --allow-newer=base,template- haskell,primitive,ghc-prim --disable-library-profiling -j1 --ghc- options='-v -ddump-to-file -ddump-tc-trace' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13152: Provide a mechanism to notify build system when .hi file is ready
by GHC 20 Feb '17

20 Feb '17

#13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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 one-shot mode GHC typically finishes writing the interface file around halfway through compilation. A dependent module (if it doesn't use Template Haskell) only needs the interface file to start building. If we could start building a module as soon as all its dependencies' interface files are ready, we would cut the critical path by about a factor of 2; and parallelism in the GHC build tree is currently low enough that this should give significantly lower build times even on only modestly parallel systems. The first obstruction to doing this is that there isn't a good way to know when the interface file becomes ready. I propose the following simple and flexible mechanism: * Add a GHC command-line argument `-finterface-file-finished=N,F,str`. When GHC has finished writing the interface file it uses the `send` system call to send the string `str` to file descriptor `N` using flags `F`. The build system might then invoke GHC with file descriptor `N` open to a UNIX datagram socket, for example, and generate a unique `str` for each interface file dependency. Alternative suggestions are more than welcome. I tentatively milestoned this for 8.2 since it would be nice to have this available in the bootstrapping compiler when we switch to Hadrian, and the GHC-side implementation should be simple. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12428: Allow pattern synonyms to optionally carry coerceability
by GHC 20 Feb '17

20 Feb '17

#12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Aside from their more interesting abilities, pattern synonyms can be used for name management. For example, if a module exports a type with a data constructor named `A`, and also re-exports a type with a data constructor named `A`, it can use a pattern synonym to rename the imported constructor. If the type is a `newtype`, this pattern synonym will not carry coerceability. Sometimes, this is exactly what one would desire (an "unsafe" module breaking through a newtype abstraction may wish to allow importers to confine coerceability). Other times, it's not (pattern synonym just for name control). When defining a pattern synonym for a type in a module in which that type is coerceable, it would be nice to be able to tell GHC that the pattern synonym should carry coerceability. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied
by GHC 20 Feb '17

20 Feb '17

#11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- in an effort to simulate the TypeError close type family in userland, I was doing a bit of experimentation with type families in ghc 7.10 and 8.0 RC2, and i was surprised to find that i can't get fully applied closed type families to reduce "strictly" when they are fully applied to concrete arguments within a Constraint Tuple. Roughly, I want to be able to write "Assert x" style predicates in a type signature, and have those be checked/ reduced at the definition site rather than the use site. It seems like what I would have to do is do a slight indirection the form {{{ publicFunName :: SimpleType c1 c2 --- c1 c2 are two concrete types publicFunName ... = guardedFun where guardedFun :: (MyClosedTypeFamAssert c1 c2)=> SimpleType c1 c2 guardedFun ... = ... -- myClosedTypeFamAssert (x :: *) (y :: *) :: Constraint }}} I guess this SORTOF makes sense that it doesn't get reduced strictly at the definition site (though its a sort of normalization i feel like). I think the sibling computation where i have `myClosedTypeFamAssert (x :: *) (y :: *) :: Bool` and have the guard be ('True ~ myClosedTypeFamAssert c1 c2 ), but I was hoping i could have things look a teeny bit more "Assertion" style for aesthetical reasons enclosed below is a self contained module that exhibits a more worked out example {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies, TypeOperators #-} {-# LANGUAGE DataKinds, GADTs #-} {-# LANGUAGE TypeInType, ConstraintKinds #-} module Main where import GHC.Types (Constraint,TYPE,Levity(..)) main = print (7 :: Int)-- this works -- main = print (sevenBad :: Int ) -- this does error, but its at the use site rather than definition site! -- using this one ""works"", but results in a VERY confusing type error involving -- type family WorstClosedStuckError (x :: a) :: Constraint where WorstClosedStuckError a = (False ~ True) --- empty closed type families are ONLY allowed as of ghc 8.0 type family ClosedStuckSilly (x :: a) :: b where type family ClosedStuckSillyConstr (x :: a) :: Constraint where --- this is analogous to a version of the TypeError family in GHC.TypeLits in 8.0 onwards --- but kind polymorphic closed empty type families dont seem to trigger a type error in the definition site --- but rather in the USE site type family ClosedStuckTypeConstr (x :: TYPE Lifted) :: Constraint where type family ClosedStuckType (x :: TYPE Lifted) :: b where --- these two seem to work OK -- these two only only report an error once I resolve the constraint on a to something like Int etc sevenBad :: (ClosedStuckSilly 'True , Num a) => a sevenBad = 7 sevenOtherBad :: (ClosedStuckSillyConstr 'False, Num a) => a sevenOtherBad = 7 -- this one fails to type check at the definition site, but has a SUPER confusing -- error about allow ambiguous types sevenBadWorst :: (WorstClosedStuckError 'False, Num a) => a sevenBadWorst = 7 sevenOKButNotUseful :: (ClosedStuckType Bool, Num a) => a sevenOKButNotUseful = 7 -- i have to do an indirection to force an "assertion" / "reduction", the following triggers the error as expected sevenIndirect :: Num a => a sevenIndirect = sevenBad }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13072: Move large tuples to a separate module in base
by GHC 20 Feb '17

20 Feb '17

#13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.1 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: -------------------------------------+------------------------------------- Quoting from my message to ghc-devs@: > It occurred to me that rather than moving just these instances to a new module, we could move the large tuples themselves to a new module Data.LargeTuple and put the instances there. The Prelude would reexport the large tuples, so there would be no user-visible change. According to my experiments, GHC should never have to read the Data.LargeTuple interface file unless a program actually mentions a large tuple type, which is presumably rare. We could then also extend the existing instances for Eq, Show, etc., which are currently only provided through 15-tuples. > > A nontrivial aspect of this change is that tuples are wired-in types, and they currently all live in the ghc-prim package. I'm actually not sure why they need to be wired-in rather than ordinary types with a funny- looking name. In any case I need to look into this further, but the difficulties here don't seem to be insurmountable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15