August 2016 - ghc-tickets

[GHC] #11084: Some type families don't reduce with :kind!
by GHC 03 Feb '19

03 Feb '19

#11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Sadly, I'm unable to reproduce this without `singletons`. :( Observe: {{{ > ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Promotion.Prelude -- singletons-2.0.1 Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = Data.Singletons.Prelude.List.Case_1628035408 'True 'True 'True '[] (Data.Singletons.Apply (Data.Singletons.Apply (:==$) 'True) 'True) Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = JustSym1 'True }}} Note that the exact same command run twice yields different results. I tried peeking at `-ddump-tc-trace` but got nothing of use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12001: RFC: Add pattern synonyms to base
by GHC 02 Feb '19

02 Feb '19

#12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 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: -------------------------------------+------------------------------------- Since we have pattern synonyms it's worth considering if some belong in base: [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex-Lens.html Data.Complex.Lens] contains patterns that could be defined in base, here are some more suggestions: === Data.Array === {{{#!hs pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> (low'high, xs)) where ArrayIx low'high xs = array low'high xs }}} === Data.Bits === {{{#!hs pattern ZeroBits :: (Eq a, Bits a) => a pattern ZeroBits <- ((== zeroBits) -> True) where ZeroBits = zeroBits pattern BitSize :: Bits a => Int -> a pattern BitSize n <- (bitSizeMaybe -> Just n) pattern Signed :: Bits a => a pattern Signed <- (isSigned -> True) pattern Unsigned :: Bits a => a pattern Unsigned <- (isSigned -> False) pattern PopCount :: Bits a => Int -> a pattern PopCount n <- (popCount -> n) }}} === Data.Char === {{{#!hs pattern ControlChar :: Char pattern ControlChar <- (isControl -> True) pattern SpaceChar :: Char pattern SpaceChar <- (isSpace -> True) }}} === Data.Complex === {{{#!hs pattern Conjugate :: Num a => Complex a -> Complex a pattern Conjugate a <- (conjugate -> a) where Conjugate a = conjugate a pattern Polar :: RealFloat a => a -> a -> Complex a pattern Polar m theta <- (polar -> (m, theta)) where Polar m theta = mkPolar m theta -- See https://github.com/ekmett/lens/issues/653 pattern Real :: Num a => a -> Complex a pattern Real r <- r :+ _ where Real r = r :+ 0 pattern Imaginary :: Num a => a -> Complex a pattern Imaginary i <- _ :+ i where Imaginary i = 0 :+ i }}} === GHC.Float === {{{#!hs pattern NegativeZero :: RealFloat a => a pattern NegativeZero <- (isNegativeZero -> True) where NegativeZero = -0 pattern Denormalized :: RealFloat a => a pattern Denormalized <- (isDenormalized -> True) pattern NaN :: RealFloat a => a pattern NaN <- (isNaN -> True) where NaN = 0 / 0 -- How ever negative infinity is handled pattern Infinity :: RealFloat a => a pattern Infinity <- ((== 1 / 0) -> True) where Infinity = 1 / 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11004: hsc2hs does not handle single quotes properly
by GHC 01 Feb '19

01 Feb '19

#11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | 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: -------------------------------------+------------------------------------- The tool gets confused by quotes for promoted constructors (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/promotion.h… #promotion-syntax). Here's an example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} gets translated into {{{#!hs {-# LINE 1 "Test.hsc" #-} {-# LANGUAGE DataKinds #-} {-# LINE 2 "Test.hsc" #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} Then GHC complains about `#size`: {{{ Test.hsc:10:16: parse error on input ‘#’ }}} Judging from the source of utils/hsc2hs/HSCParser.hs, the tool treats single quotes the same way as double quotes. I.e. it looks for balanced, possibly multiline, strings delimited by '. At least, it seems unnecessary to expect newlines in that string-like structure, because character literals cannot contain newlines, AFAIK. It's interesting to note that this problem looks like a bit of an edge case, since highlighting in the ticket seems to be confused as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11222: Teach strictness analysis about `catch`-like operations
by GHC 31 Jan '19

31 Jan '19

#11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the `catch#` primop, {{{#!hs catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -- ^ thing to catch exceptions from -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -- ^ exception handler -> State# RealWorld -> (# State# RealWorld, a #) }}} Semantically, this operation will always evaluate its first argument. Ideally we would indicate this in the primop's strictness signature in `primops.txt.pp`. Sadly, we can't do this at the moment due to a subtle wrinkle (discovered in #10712): Consider, {{{#!hs let r = \st -> raiseIO# blah st in catch (\st -> ...(r st)..) handler st }}} If we give the first argument of catch a strict signature, we'll get a demand `C(S)` for `r`; that is, `r` is definitely called with one argument, which indeed it is. The trouble comes when we feed `C(S)` into `r`'s RHS as the demand of the body as this will lead us to conclude that the whole `let` will diverge; clearly this isn't right. As Simon noted in ticket:10712#comment:4, > There's something very special about catch: it turns divergence into non-divergence. In order to apply a proper strictness signature to `catch`-like operations we would need to teach the strictness analyzer about this property. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12092: Wrong error message with TypeApplications
by GHC 31 Jan '19

31 Jan '19

#12092: Wrong error message with TypeApplications -------------------------------------+------------------------------------- Reporter: kwf | 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: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I write the following: {{{#!hs {-# language TypeApplications #-} module Bug where huh = spam @Int }}} I expect to get the error: {{{ • Variable not in scope: spam • Perhaps you meant ‘span’ (imported from Prelude) }}} But instead, I get the error: {{{ • Cannot apply expression of type ‘t0’ to a visible type argument ‘Int’ • In the expression: spam @Int In an equation for ‘huh’: huh = spam @Int }}} While it is //technically// true that I cannot apply an out-of-scope identifier to a visible type argument, this is probably the less useful error to receive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9173: Better type error messages
by GHC 27 Jan '19

27 Jan '19

#9173: Better type error messages ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Generating better type-error messages is a hoary chestnut, but Herbert brought my attention to [https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_begi… this thread on reddit], which has the following idea. At the moment, from {{{ module Foo where addThree = \x -> x + 3 :: Int y = addThree $ Just 5 }}} we get this error: {{{ Foo.hs:2:20 Couldn't match expected type `Int' with actual type `Maybe a0' In the return type of a call of `Just' In the second argument of `($)', namely `Just 5' In the expression: addThree $ Just 5 }}} Maybe we could generate this instead {{{ Foo.hs:2:20 inferred: "Just 5" has type "Maybe a0" expected: second argument of "($)" must have type "Int" in the expression: addThree $ Just 5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #12364: Demand analysis for sum types
by GHC 25 Jan '19

25 Jan '19

#12364: Demand analysis for sum types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- While working on #10613 it crossed my mind that it might be worthwhile to expand the demand type also onto sum types. So instead of {{{ | UProd [ArgUse] -- Product }}} we would have {{{ | UData [[ArgUse]] -- Data type }}} and a function like {{{ fromMaybe :: a -> Maybe a -> b }}} would have a signature of {{{ <1*U><1*U(;1*U)> }}} which indicates that the second argument of `fromMaybe` is evaluated at most once; the first constructor of the result has no arguments, the second (separated by `;`) has one argument which is also used at most once. I could imagine that this gives a lot of useful information with parsers and other code that repeatedly retuns stuff wrapped in a `Maybe` or similar type. Now, sum types are often recursive (`[]`…), and we probably want to be smarter about recursion here. But note that this is not a new problem. If you write {{{ data Stream = Stream Int Stream Stream Stream foo (Stream 0 x y z) = 0 foo (Stream 1 x y z) = foo x foo (Stream 2 x y z) = foo y foo (Stream _ x y z) = foo z }}} you already get huge demand signatures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9476: Implement late lambda-lifting
by GHC 25 Jan '19

25 Jan '19

#9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 22 Jan '19

22 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #9279: Optimisation bug
by GHC 18 Jan '19

18 Jan '19

#9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26