August 2018 - ghc-tickets

[GHC] #11350: Allow visible type application in patterns
by GHC 28 Aug '18

28 Aug '18

#11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructors (and pattern synonyms) when treated as expressions may be applied to types: {{{#!hs {-# LANGUAGE TypeApplications #-} Nothing :: Maybe a Nothing @() :: Maybe () pattern Pair :: a -> a -> (a, a) pattern Pair x y = (x, y) Pair :: a -> a -> (a, a) Pair @Int :: Int -> Int -> (Int, Int) }}} But using them in patterns won't parse: {{{#!hs -- parse error in pattern: @Int maybeToList :: Maybe Int -> [Int] maybeToList (Nothing @Int) = [] maybeToList (Just @Int x) = [x] -- parse error in pattern: @Int add :: (Int, Int) -> Int add (Pair @Int x y) = x + y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak).
by GHC 28 Aug '18

28 Aug '18

#15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (FFI) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**. [[br]][[br]] There are four files attached to this ticket. * **HaskellExports.hs** contains exact one foreign export function; * **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference; * **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory); * **build.sh** is a script for building the library. [[br]] The main program was built with MSVC 2015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 28 Aug '18

28 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): There's another way to go "generational" that takes into account the fact that (I imagine) stable names tend to live a long time. We could have just one hash table, but also keep a list of all the stable names whose underlying objects are in the nursery. When we perform a minor collection, we go through that list and delete the dead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 28 Aug '18

28 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I didn't mention per-capability hash tables, only per-generation. per- capability might be worthwhile to avoid locking overhead, but my nagging concern about all this is that I'm not sure what we're optimising for. Are there any heavy users of StableNames that would benefit from optimisation here, or are people avoiding StableNames because they aren't efficient enough? Or is the main concern implementation complexity? Adding per- generation tables would increase complexity, it's not clear to me that going to per-generation hash tables would result in a simpler implementation, even if the no-stable-table idea was implemented too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility
by GHC 28 Aug '18

28 Aug '18

#15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #8423 #15546 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reference I found for closed type families with compatible equations is: https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/popl137-eisenberg.pdf There in Definition 8 in section 3.4 it states: Definition 8 (Compatibility implementation). The test for compatibility, written compat(p, q), checks that unify(lhsp, lhsq) = Ω implies Ω(rhsp) = Ω(rhsq). If unify(lhsp, lhsq) fails, compat(p, q) holds vacuously. Examine the following families: {{{#!hs type family If (a :: Bool) (b :: k) (c :: k) :: k where If False a b = b If True a b = a type family Eql (a :: k) (b :: k) :: Bool where Eql a a = True Eql _ _ = False type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql x y) (Just x) Nothing Test a a = a Test Nothing _ = Nothing Test _ Nothing = Nothing }}} Applying the check to the equations 1 and 2 of `Test` we get: unify(<`Just x`, `Just y`>, <`a`, `a`>) = Ω = [`a` -> `Just x`, `y` -> `x`] Ω(`a`) = `Just x` = `If (Eql x x) (Just x) Nothing` = Ω(`If (Eql x y) (Just x) Nothing`) Therefore the equations must be compatible, and when tidying `forall a. p a -> p (Test a a)` the application should reduce to `forall a. p a -> p a` That doesn't happen: {{{#!hs > :t undefined :: p a -> p (Test a a) p a -> p (Test a a) }}} Examining the IfaceAxBranches (cf #15546) we see: {{{#!hs axiom D:R:Test:: Test a ('Just x) ('Just y) = If (Eql x y) ('Just x) 'Nothing Test k a a = a (incompatible indices: [0]) Test k 'Nothing _ = 'Nothing Test k _ 'Nothing = 'Nothing }}} GHC did not consider the two equations compatible. Digging into why, I came across this ticket: #8423, in which a potentially unbounded (and indefinite) number of type family reductions was necessary to evidence Ω(rhsp) = Ω(rhsq). I don't claim to fully understand goldfire's ticket:8423#comment:10, but the issue is clear: reducing type families while doing a compartibility check might depend on other compatibility checks already being done, including a check depending on itself in which case we are interested in the biggest fixed point (why?). The family here doesn't require any of that special consideration because `Eql x x` reduces right away without any compatibility checks, and `If` is essentially open (indeed making `If` open doesn't help anything). This brings the question: is something like goldfire's described algorithm (or a simplification thereof) something we would like to have in GHC or is that too complex? What is the status on the implementation of that algorithm? P.S: An interesting workaround is adding an `If t c c = c` equation (compatible), and then writing `Test` as: {{{#!hs type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql (Just x) (Just y)) (Just x) Nothing Test a a = If (Eql a a) a Nothing Test Nothing a = If (Eql Nothing a) Nothing Nothing Test a Nothing = If (Eql a Nothing) Nothing Nothing }}} This lets GHC discover the necessary equalities without reducing type families, yet erase the workaround'ed type family applications immediately. P.P.S: In ticket:15546#comment:4 I mixed up left and right, it's the RHS that should be/are not reduced. This probably confused SPJ a lot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining.
by GHC 28 Aug '18

28 Aug '18

#15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- I have some intermediate core of the form: {{{ -- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0} cseAlts_s1dD [Occ=Once!T[1]] :: T -> Int# [LclId, CallArity=1, Str=<S,1*U>] cseAlts_s1dD = \ (lamVar_s1dw [Occ=Once!, Dmd=<S,1*U>, OS=OneShot] :: T) -> case lamVar_s1dw of wild_Xc [Dmd=<L,A>] { __DEFAULT -> 1#; B -> 2#; C -> 3# } -- RHS size: {terms: 14, types: 3, coercions: 0, joins: 0/0} $wfmerge_s1cZ [InlPrag=NOUSERINLINE[0]] :: T -> T -> Int# [LclId, Arity=2, CallArity=2, Str=<S,1*U><L,1*U>] $wfmerge_s1cZ = \ (w_s1cU [Occ=Once!, Dmd=<S,1*U>] :: T) (w_s1cV [Occ=Once*, Dmd=<L,1*U>] :: T) -> case w_s1cU of wild_XA [Dmd=<L,A>] { __DEFAULT -> -1#; A -> 2#; B -> cseAlts_s1dD w_s1cV; C -> cseAlts_s1dD w_s1cV } }}} Which after the simplifier ran got inlined into the branches to give us: {{{ fmerge = \ (w_s1cU :: T) (w_s1cV :: T) -> case w_s1cU of { __DEFAULT -> GHC.Types.I# -1#; A -> GHC.Types.I# 2#; B -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# }; C -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# } } }}} What I would really like GHC to do instead though is to make `cseAlts_s1dD` a join point when possible. This would eliminate both the call overhead AND the call duplication. The current behavior seems fine when we can't make it a join point. But when we can we should try to take advantage of that opportunity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15546: Display coaxiom branch incompatibilities in GHCi
by GHC 28 Aug '18

28 Aug '18

#15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: TypeFamilies, | Operating System: Unknown/Multiple GHCi | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the only way to figure out how GHC figured out compatibility of branches in a closed type family is to compile it to `.hi` and then sieve through `--show-iface` output. Something as simple this should suffice: {{{#!hs > :i == type family (==) (a :: k) (b :: k) :: Bool where (==) (f a) (g b) = (f == g) && (a == b) (==) a a = 'True -- incompatible with: 0 (==) _1 _2 = 'False -- incompatible with: 0, 1 -- Defined in ‘Data.Type.Equality’ infix 4 == }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 27 Aug '18

27 Aug '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation
by GHC 27 Aug '18

27 Aug '18

#15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match. {{{#!hs data (:+:) f g a = Inl !(f a) | Inr !(g a) data A data B data Foo l where Foo :: Foo A data Bar l where Bar :: Bar B type Sig = Foo :+: Bar fun :: Sig B -> Int fun (Inr Bar) = 1 }}} This report came from https://stackoverflow.com/questions/16225281/gadts- failed-exhaustiveness-checking . Without strictness annotations, this is indeed a failed exhaustive check, due to bottom. I spoke to Richard Eisenberg at PLDI a few days ago, and he informed me that, if this warning did not disappear with strictness annotations, it was a bug. I added strictness annotations, and it did not disappear. I've tried all combinations of using strictness annotations and/or running with `{-# LANGUAGE Strict #-}`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method
by GHC 27 Aug '18

27 Aug '18

#15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.3 Haskell | 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: -------------------------------------+------------------------------------- If you try to reify a type class in Template Haskell, as in the following example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH class C a where method :: a $(pure []) main :: IO () main = putStrLn $(reify ''C >>= stringE . pprint) }}} You'll discover something strange: {{{ $ /opt/ghc/8.4.3/bin/runghc Bug.hs class Bug.C (a_0 :: *) where Bug.method :: forall (a_0 :: *) . Bug.C a_0 => a_0 }}} Notice how `method` has a completely redundant `forall (a_0 :: *) . Bug.C a_0 =>`! I find this very strange, and would have expected to simply see `Bug.method :: a_0` instead. Currently, I have to work around this oddity by manually stripping off the `forall (a_0 :: *) . Bug.C a_0 =>` myself, but it would be nice if I didn't have to do so. Does this proposal sound reasonable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5