- ghc-tickets - Haskell.org

[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 21 Feb '17

21 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 21 Feb '17

21 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 21 Feb '17

21 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 21 Feb '17

21 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

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 20 Feb '17

20 Feb '17

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 #13308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #9839 => #9839 #13308 Comment: When parsing arguments to flags ghc treats leading whitespace different depending on the flag. ghc +RTS '-N 2' -s -RTS --version Here '-N 2' is parsed as -N2 ghc +RTS '-s file' -RTS --version Here '-N 2' is parsed as '\ file', a filename starting with a space. If this rework ever happens leading spaces in arguments should either be uniformly ignored or treated as errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13308: Treat leading whitespace in rts flag arguments in a uniform way
by GHC 20 Feb '17

20 Feb '17

#13308: Treat leading whitespace in rts flag arguments in a uniform way -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4243 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When parsing argument flags ghc treats leading whitespace different depending on the flag. * `ghc +RTS '-N 2' -s -RTS --version` Here '-N 2' is parsed as -N2 * `ghc +RTS '-s file' -RTS --version` Here '-N 2' is parsed as '\ file', a filename starting with a space. * `ghc +RTS -N 2 -s -RTS --version` Here `2` is a unexpected argument. The usage info indicates no space is allowed in between flags and arguments making the first point a minor bug. It's never an issue when executing from a shell since it filters out unquoted spaces, however it can trip someone up when passing arguments explicitly via exec. If we remove leading spaces for file names however we make it impossible to use filenames starting with whitespace since we cant tell if the space was included by accident or quoted by the shell. But I also have never seen a file starting with whitespace that was created intentionally so maybe that is a worthwhile tradeoff. If the argument Parser #4243 ever get's rewritten maybe this could be made uniform one way or the other. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Feb '17

20 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The main difference seems to come from this change... Interesting! There are two changes in that commit: * Making data con wrappers have `ug_unsat_ok = unSaturatedOk`. I buy this. Can you try the effect of this change alone? It's entirely unrelated to nested-CPR. It would be good to isolate that perf bump from the perf changes due to nested CPR. * Making data con wrapper have `ug_boring_ok = boringCxtOk`. I'm not sure I buy this in full. In `Note [Inline data constructor wrappers aggresively]` there's a claim that we get better nested-CPR info. That's true if we have a polymorphic bang argument (e.g. `data T a = MkT !a`) but for a monomorphic one like `data S = MkS !Int` we'll unpack it. So I think the benefit comes only for polymorphic bangs. And there is a cost to aggressive inlining, so we don't want to do it gratuitously. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Feb '17

20 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): == mandel and gcd The main difference seems to come from [https://github.com/takano- akio/ghc/commit/1edc47406dd2f5da9925978b01a1724028bd576e this change], which makes `integer-gmp` allocate less by inlining wrappers for `S#`, `Jp#` etc. Actually this small change seems to be responsible for the much of the allocation improvement in this branch: {{{ gcd +0.8% -21.4% 0.039 0.040 0.0% integer +1.1% -1.5% +5.0% +5.1% 0.0% mandel +1.1% -24.4% 0.070 0.070 0.0% -------------------------------------------------------------------------------- Min -0.0% -24.4% -38.7% -38.5% 0.0% Max +1.1% 0.0% +13.7% +13.6% +14.4% Geometric Mean +0.3% -0.6% -6.9% -6.9% +0.1% }}} Perhaps I should try go get this change merged, separately from the rest of the nested CPR work. == Binary size increase I had a brief look at `nofib/real/fluid/Jcb_method.hs`, which showed a +60% increase in the binary size, but I wasn't able to figure out why the change happened. !SpecConstr now seems to duplicate a big function, but I don't know what caused this (yet). == Wiki page I think the content under wiki:NestedCPR is mostly valid, because all I have done so far is essentially just to rebase nomeata's branch on top of the join-point commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0