From ghc-devs at haskell.org Sat Jul 1 05:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 05:19:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.abe99a32f9398eec690f395ed0460a4d@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Me: 1, Bug: 0. Details and patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 06:24:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 06:24:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.c1c4fe220f9b7b9e5d04522d1cddcf01@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3695 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 13:30:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 13:30:48 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.4508db2d900047fa021dbd3ea2aba2d9@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 winter): * cc: winter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 14:43:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 14:43:02 -0000 Subject: [GHC] #13670: Improving Type Error Messages In-Reply-To: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> References: <049.a5addc0df97fe0916cadf9848effc25a@haskell.org> Message-ID: <064.b3982ead0f26d02d94d04e7f119e2bf5@haskell.org> #13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeErrorMessages 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 vanto): Replying to [[span(style=color: #FF0000, simonpj )]]\\ I think you should wait a little.\\ There is a contradiction to correct this without first correcting ticket {{{#9173}}}. On the other hand there is more to remove.\\ See the comment n ° 2 that I wrote in the ticket {{{#13902}}}. Many people agree to review and improve the error messages. I think that this must be done in a collegial way and not punctually.\\ This correction would be made once and for all and not a sudden blow.\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 14:47:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 14:47:37 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array Message-ID: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Sometime it is useful to compare reference equality for immutable arrays, for example when comparing vectors which are slices of arrays, we may want to know if two vectors are slices of the same array. But currently we only have `sameMutableXXXArray` primitives. A workaround may look like this: {{{ sameArray :: Array a -> Array a -> Bool sameArray arr1 arr2 = runST (do marr1 <- unsafeThawArray arr1 marr2 <- unsafeThawArray arr2 return (sameMutableArray marr1 marr2) ) }}} But the problem is for boxed arrays, this code will push an unchanged array to mutable list if it's already on older generations. Next GC will have to scan it(at least will scan its card table). I can see two solutions here, first one is to add `sameXXXArray` for all array types. The second one is somehow more complex: Currently we simply rewrite array's header to `MUT_ARR_PTRS_FROZEN0/SMALL_MUT_ARR_PTRS_FROZEN0` when we do `unsafeFreeze`. But for mutable array with no write happend, e.g. the ones with `MUT_ARR_PTRS_CLEAN/SMALL_MUT_ARR_PTRS_CLEAN` header. we can safely rewrite the header to `MUT_ARR_PTRS_FROZEN/SMALL_MUT_ARR_PTRS_FROZEN`, so that we can keep it from next GC. Then to fix previous code, we can add a freeze before returning. Of course we can do these two solutions all together ; ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 14:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 14:55:49 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.8c887091aa0d4c7c5c2ce1512c310ddb@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 winter): In fact the code in the issue report is even problematic: if we thaw an array without freezing it. we may leave it on the mutable list forever. So we have to add it anyway. But currently doing that won't save us from next GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 14:59:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 14:59:14 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.e2c1b46d98897cb90c8a265340a7f625@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 winter): I just come up a third solution to this problem: {{{ sameArray :: Array a -> Array a -> Bool sameArray arr1 arr2 = runST (do return (sameMutableArray (unsafeCoerce arr1) (unsafeCoerce marr2)) }}} Does this code safe? do i have to use unboxed version, e.g. unsafeCoerce# with array#? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 15:04:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 15:04:02 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.99033728d64da5a44c81774be813ec9e@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case {{{#!hs data Pair a = a :# a pattern Pair1 :: Pair a -> (Bool -> a) pattern Pair1 (a :# a') <- (($ False) &&& ($ True) -> (a, a')) where Pair1 (a :# _) False = a Pair1 (_ :# a') True = a' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 16:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 16:14:26 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.8020f77c166bc6923618a1e698a29d36@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): I believe that should be fine. Afterall, `sameMutableArray#` is really just a pointer comparison. However, you are right that we probably ought to have a primop for this. I'm not sure why this was overlooked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 16:22:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 16:22:25 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.05fbfd5fa8cea10f9a61a5537d104ea9@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3697 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 16:22:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 16:22:32 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.1cd7c12a4baf0e6c8e8231891e6e44f2@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 16:56:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 16:56:36 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.7cbaa2e8841e96d8d2115fda35e4668a@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 17:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 17:38:45 -0000 Subject: [GHC] #13909: Can't partially apply a data type with a visible quantifier in its kind Message-ID: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> #13909: Can't partially apply a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | 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'm not sure if this is a bug or an intended design, so I'll ask here. I want this program to typecheck: {{{#!hs {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data Hm (k :: Type) (a :: k) :: Type class HasName (a :: k) where getName :: proxy a -> String instance HasName Hm where getName _ = "Hm" }}} This is rejected, however: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:18: error: • Expecting two more arguments to ‘Hm’ Expected kind ‘k0’, but ‘Hm’ has kind ‘forall k -> k -> *’ • In the first argument of ‘HasName’, namely ‘Hm’ In the instance declaration for ‘HasName Hm’ | 11 | instance HasName Hm where | ^^ }}} The culprit appears to be the fact that `Hm` has kind `forall k -> k -> *`, which uses a visible quantifier. Does this prevent partial applications of `Hm`? Or is this simply a GHC bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 17:47:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 17:47:05 -0000 Subject: [GHC] #13907: stack upgrade fails on Mac OS In-Reply-To: <045.69034993c5ec98845ad6df721992671d@haskell.org> References: <045.69034993c5ec98845ad6df721992671d@haskell.org> Message-ID: <060.0a2c19487bd49b7721823fe56816a62b@haskell.org> #13907: stack upgrade fails on Mac OS -------------------------------------+------------------------------------- Reporter: gukoff | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12479 * milestone: => 8.0.2 Comment: This is a duplicate of #12479 which was fixed in 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 20:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 20:50:04 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) Message-ID: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13877 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a program which I believe //should// typecheck: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE Trustworthy #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality data family Sing (a :: k) class SingKind k where type Demote k = (r :: *) | r -> k fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k data SomeSing k where SomeSing :: Sing (a :: k) -> SomeSing k withSomeSing :: forall k r . SingKind k => Demote k -> (forall (a :: k). Sing a -> r) -> r withSomeSing x f = case toSing x of SomeSing x' -> f x' data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ data FunArrow = (:->) | (:~>) class FunType (arr :: FunArrow) where type Fun (k1 :: Type) arr (k2 :: Type) :: Type class FunType arr => AppType (arr :: FunArrow) where type App k1 arr k2 (f :: Fun k1 arr k2) (x :: k1) :: k2 type FunApp arr = (FunType arr, AppType arr) instance FunType (:->) where type Fun k1 (:->) k2 = k1 -> k2 $(return []) -- This is only necessary for GHC 8.0 -- GHC 8.2 is smarter instance AppType (:->) where type App k1 (:->) k2 (f :: k1 -> k2) x = f x instance FunType (:~>) where type Fun k1 (:~>) k2 = k1 ~> k2 $(return []) instance AppType (:~>) where type App k1 (:~>) k2 (f :: k1 ~> k2) x = f @@ x infixr 0 -?> type (-?>) (k1 :: Type) (k2 :: Type) (arr :: FunArrow) = Fun k1 arr k2 data instance Sing (z :: a :~: b) where SRefl :: Sing Refl instance SingKind (a :~: b) where type Demote (a :~: b) = a :~: b fromSing SRefl = Refl toSing Refl = SomeSing SRefl (~>:~:) :: forall (k :: Type) (a :: k) (b :: k) (r :: a :~: b) (p :: forall (y :: k). a :~: y ~> Type). Sing r -> p @@ Refl -> p @@ r (~>:~:) SRefl pRefl = pRefl type WhyReplacePoly (arr :: FunArrow) (from :: t) (p :: (t -?> Type) arr) (y :: t) (e :: from :~: y) = App t arr Type p y data WhyReplacePolySym (arr :: FunArrow) (from :: t) (p :: (t -?> Type) arr) :: forall (y :: t). from :~: y ~> Type type instance Apply (WhyReplacePolySym arr from p :: from :~: y ~> Type) x = WhyReplacePoly arr from p y x replace :: forall (t :: Type) (from :: t) (to :: t) (p :: t -> Type). p from -> from :~: to -> p to replace = replacePoly @(:->) replaceTyFun :: forall (t :: Type) (from :: t) (to :: t) (p :: t ~> Type). p @@ from -> from :~: to -> p @@ to replaceTyFun = replacePoly @(:~>) @_ @_ @_ @p replacePoly :: forall (arr :: FunArrow) (t :: Type) (from :: t) (to :: t) (p :: (t -?> Type) arr). FunApp arr => App t arr Type p from -> from :~: to -> App t arr Type p to replacePoly from eq = withSomeSing eq $ \(singEq :: Sing r) -> (~>:~:) @t @from @to @r @(WhyReplacePolySym arr from p) singEq from type WhyLeibnizPoly (arr :: FunArrow) (f :: (t -?> Type) arr) (a :: t) (z :: t) = App t arr Type f a -> App t arr Type f z data WhyLeibnizPolySym (arr :: FunArrow) (f :: (t -?> Type) arr) (a :: t) :: t ~> Type type instance Apply (WhyLeibnizPolySym arr f a) z = WhyLeibnizPoly arr f a z leibnizPoly :: forall (arr :: FunArrow) (t :: Type) (f :: (t -?> Type) arr) (a :: t) (b :: t). FunApp arr => a :~: b -> App t arr Type f a -> App t arr Type f b leibnizPoly = replaceTyFun @t @a @b @(WhyLeibnizPolySym arr f a) id leibniz :: forall (t :: Type) (f :: t -> Type) (a :: t) (b :: t). a :~: b -> f a -> f b leibniz = replaceTyFun @t @a @b @(WhyLeibnizPolySym (:->) f a) id -- The line above is what you get if you inline the definition of leibnizPoly. -- It causes a panic, however. -- -- An equivalent implementation is commented out below, which does *not* -- cause GHC to panic. -- -- leibniz = leibnizPoly @(:->) leibnizTyFun :: forall (t :: Type) (f :: t ~> Type) (a :: t) (b :: t). a :~: b -> f @@ a -> f @@ b leibnizTyFun = leibnizPoly @(:~>) @_ @f }}} GHC 8.2.1 and HEAD panic on the definition of `leibniz`, however: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170623 for x86_64-unknown-linux): repSplitTyConApp_maybe (f_a5vT[sk:2] |> Sym (Trans (Sym (D:R:Funk1:->k2[0] _N _N)) (D:R:Funk1:->k2[0] _N <*>_N))) a_a5vU[sk:2] (f_a5vT[sk:2] |> Sym (Trans (Sym (D:R:Funk1:->k2[0] _N _N)) (D:R:Funk1:->k2[0] _N <*>_N))) a_a5vU[sk:2] k2_a5l0 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1122:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Interestingly, GHC 8.0.1 and 8.0.2 do not give the same panic—they give the panic from #13877: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:134:64: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: k2_a4KV Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 20:50:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 20:50:18 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.ff6dd7c95f972c24acb8ef9af47e5995@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 1 21:55:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Jul 2017 21:55:34 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.a53781063076f68a6ef6f02c1ca35953@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Comment (by mpickering): I looked at this. Firstly, 8.2.1 is much faster than 8.0.2. So I looked at the core for both versions. The key function is `wcJH` which in 8.0.2 calls `$winsertWith` with a dictionary argument `$fPrimMonadST`. In 8.2.1, this function does get specialised (see `$s$winsertWith`) which accounts for the difference. When the specialisation happens, the type of the specialised function is {{{#!hs $w$sinsertWith :: MutVar# (PrimState (ST RealWorld)) (HashTable_ (PrimState (ST RealWorld)) ByteString v) -> v -> v -> v -> ByteString -> v -> State# RealWorld -> (# State# RealWorld, () #) }}} The specialisation produced by the specialise pragma is instead, {{{#!hs $w$sinsertWith :: MutVar# (PrimState (ST s)) (HashTable_ (PrimState (ST s)) ByteString v) -> v -> v -> v -> ByteString -> v -> State# s -> (# State# s, () #) }}} as such the `s` parameter is not specialised to `RealWorld`. Changing the specialise pragma to {{{#!hs {-# SPECIALIZE J.insertWith::(Hashable k,Eq k) => J.HashTable RealWorld k v -> (v->v->v) -> k -> v -> ST RealWorld () #-} }}} makes the performance the same. Digging much deeper, deep in the definition of the specialised insertWith function there is a call to `checkResize`. Without the pragma, this is specialised but with the pragma, it is not specialised and passed three dictionary arguments. Fixing `s` in the specialise pragma to `RealWorld`. also causes `checkResize` to be specialised which is why the performance improves. So it seems that the specialisation is not as good with the manual pragma as GHC is specialising more than the pragma in order to also remove a type argument. This means that other functions called by `insertWith` can also be specialised, if we do not specialise on `s` as well then their type will mention this type argument `s` which means that calls to this function are removed by `dumpBindUDs` at the top level. GHC itself will not remove the type argument `s` as we only specialise on dictionary arguments - it does seem like we might be able to do better here. If we were to further specialise `insertWith` in order to also remove the type argument then it would cause `checkResize` to specialise as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 01:48:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 01:48:17 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.1a628682424502428dc62d6e40354b38@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Comment (by jberryman): Thanks so much for looking into this. I maybe wasn't clear in the body that the reason I filed the ticket was I assumed that GHC would try to choose the best specialization from those in scope (since my intuition was specialize pragmas behave sort of like type classes in the way they leak via `import` statements) and from whatever specializations it might perform in context. But maybe this is expected behavior, and a manual specialization will always take precedence? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 03:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 03:01:31 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.6e92b376c484b20c8300a13bb6e57188@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 13722 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 Comment: It seems that the testcase is getting stuck on `pthread_mutex_destroy` and `pthread_cond_destroy`. Commenting both of these calls in `destroyCallbackQueue` allows the test to run to completion. It seems that the issue is that the `do { ... } while(1)` loop in `callback` never terminates and therefore the mutex is never unlocked. I suspect this fails only now because `glibc` is now more strict about checking that the mutex is not locked before freeing it. Simon, how did you intend for the loop in `callback` to terminate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 05:00:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 05:00:25 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions Message-ID: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> #13911: GHC RTS VEH swallowing exceptions --------------------------------------+---------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- On ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches. #13108 improved things a little by giving some basic info upon segfaults, but otherwise left everything as is. Rather than trying to catch all exceptions, I think it would be more worthwhile to leave them uncaught, and let current & future tools have an eyes open approach to debugging. If something needs to go in the place of the global handler, perhaps SetUnhandledExceptionFilter is of use? VEH overrides all other exception handlers as far as I'm aware (C++, SEH, .NET), so trying to interop with any other code that wants to handle it's own exceptions won't work unless said code is also using VEH. This is causing an issue for some code I've been working on, and I've documented similar to this bug report there also: https://gitlab.com/tim-m89/clr-haskell/issues/25#note_33960203 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 07:11:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 07:11:05 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.c4149611522e914a2bc4240a1a59b949@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another occurrence of this bug: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Foo where data family Sing (a :: k) data instance Sing (z :: Bool) = z ~ False => SFalse | z ~ True => STrue }}} {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Foo type family ElimBool (p :: Bool -> Type) (b :: Bool) (s :: Sing b) (pFalse :: p False) (pTrue :: p True) :: p b where ElimBool _ _ SFalse pFalse _ = pFalse ElimBool _ _ STrue _ pTrue = pTrue }}} With GHC 8.0.2, you get this error: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:16: error: • Expected kind ‘Sing _’, but ‘'SFalse’ has kind ‘Sing 'False’ • In the third argument of ‘ElimBool’, namely ‘SFalse’ In the type family declaration for ‘ElimBool’ Bug.hs:12:16: error: • Expected kind ‘Sing _1’, but ‘'STrue’ has kind ‘Sing 'True’ • In the third argument of ‘ElimBool’, namely ‘STrue’ In the type family declaration for ‘ElimBool’ }}} But with 8.2.1, you get this: {{{ GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:16: error: • Expected kind ‘Sing _’, but ‘'SFalse ('Data.Type.Equality.C:~ ('GHC.Types.Eq# <>))’ has kind ‘Sing 'False’ • In the third argument of ‘ElimBool’, namely ‘SFalse’ In the type family declaration for ‘ElimBool’ | 11 | ElimBool _ _ SFalse pFalse _ = pFalse | ^^^^^^ Bug.hs:12:16: error: • Expected kind ‘Sing _1’, but ‘'STrue ('Data.Type.Equality.C:~ ('GHC.Types.Eq# <>))’ has kind ‘Sing 'True’ • In the third argument of ‘ElimBool’, namely ‘STrue’ In the type family declaration for ‘ElimBool’ | 12 | ElimBool _ _ STrue _ pTrue = pTrue | ^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 07:28:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 07:28:18 -0000 Subject: [GHC] #13912: Disparity in error message in GHCi with : load vs writing directly in GHCi Message-ID: <044.01d8bb493cc476238db527287ee2dc34@haskell.org> #13912: Disparity in error message in GHCi with : load vs writing directly in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ module Maintest where a:: Int a = 'a' main = print "b" }}} If I load this program with the command {{{:load}}} its answer is\\ {{{ Prelude> :l maintest [1 of 1] Compiling Maintest ( maintest.hs, interpreted ) maintest.hs:4:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' | 4 | a = 'a' | ^^^ Failed, modules loaded: none. Prelude> }}} If I write this program directly in GHCi, its answer is\\ {{{ Prelude> :{ Prelude| module Maintest where Prelude| a:: Int Prelude| a = 'a' Prelude| main = print "b" Prelude| :} :20:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' Prelude> }}} This information has disappeared\\ {{{ | 4 | a = 'a' | ^^^ }}} The version of GHCi used is this one {{{GHCi, version 8.2.0.20170507}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 07:44:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 07:44:11 -0000 Subject: [GHC] #13913: Can't apply higher-ranked kind in type family Message-ID: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> #13913: Can't apply higher-ranked kind in type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- This code doesn't typecheck due to `F2`: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind f :: (forall (a :: Type). a -> a) -> Bool f g = g True type F1 (g :: forall (a :: Type). a -> a) = g True type family F2 (g :: forall (a :: Type). a -> a) :: Bool where F2 g = g True }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:14:6: error: • Expected kind ‘forall a. a -> a’, but ‘g’ has kind ‘Bool -> Bool’ • In the first argument of ‘F2’, namely ‘g’ In the type family declaration for ‘F2’ | 14 | F2 g = g True | ^ }}} This is surprising to me, since `F2` seems like the type family counterpart to `f` and `F1`, both of which typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 07:44:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 07:44:21 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.d86613e1438fac310c708f6d926666de@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 10:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 10:02:09 -0000 Subject: [GHC] #13914: -fignore-asserts flag not handled by recompilation checker Message-ID: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> #13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.3 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: -------------------------------------+------------------------------------- As demonstrated below, `-fignore-asserts` is not stored in .hi files and not checked by recompilation checker. {{{ $ cat main.hs module Main where import Control.Exception main = do assert False (putStrLn "OK") $ ghc main.hs [1 of 1] Compiling Main ( main.hs, main.o ) Linking main ... $ ./main main: Assertion failed CallStack (from HasCallStack): assert, called at main.hs:6:5 in main:Main $ ghc main.hs -fignore-asserts $ ./main main: Assertion failed CallStack (from HasCallStack): assert, called at main.hs:6:5 in main:Main }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 10:10:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 10:10:00 -0000 Subject: [GHC] #13914: -fignore-asserts flag not handled by recompilation checker In-Reply-To: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> References: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> Message-ID: <058.175b4febf01dfb55a248264bbf3ff18e@haskell.org> #13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3698 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D3698 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 10:10:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 10:10:34 -0000 Subject: [GHC] #13914: -fignore-asserts flag not handled by recompilation checker In-Reply-To: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> References: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> Message-ID: <058.6abc89d8f1f7601bbfac66cfbb42c2c7@haskell.org> #13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3698 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 15:47:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 15:47:10 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.ef78e3bc0e023d6bf33f0a7157da6e02@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): I think I agree with bgamari here. Although we haven't removed `return` from `Monad` entirely, we've already taken the important step of refactoring just about all of `base` to define things first and foremost in terms of `pure`, and defining `return = pure` elsewhere. At this point, making another change to the semantics of `WrapMonad`'s `return` instance just for this use case feels pointless in the long run since, as others have noted, `return` really should work the same as `pure` from here on out in anticipation of `return`'s eventual removal from the `Monad` class. As for a solution to your problem, I'd suggest your idea of having another wrapper `newtype` that uses `Pointed` and `Monad` to retrofit `Applicative` instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 16:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 16:06:41 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance Message-ID: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Due to #12088, you can't define a data family instance and promote it in the same module. One could, up until GHC 8.2, work around this using (somewhat obscure) wisdom: define the data family instance in a separate module from where it's promoted. For example, `Bug` typechecks in GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Foo where data family T a data instance T Int = MkT }}} {{{#!hs {-# LANGUAGE TypeInType #-} module Bug where import Foo data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} However, this stopped typechecking in GHC 8.2: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:1:1: error: Can't find interface-file declaration for variable Foo.$tc'MkT Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error | 1 | {-# LANGUAGE TypeInType #-} | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 16:50:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 16:50:28 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.e4111b2f0cd459344871055d2b4535cd@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | TypeFamilies, Typeable 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) * keywords: TypeInType, TypeFamilies => TypeInType, TypeFamilies, Typeable Comment: This regression was introduced in 8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497 (Type-indexed Typeable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 16:59:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 16:59:15 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.9e96f40af4fbe0ac737931752274747b@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | TypeFamilies, Typeable 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, GHC isn't actually so great about //using// the `Typeable` instance for `MkT`, regardless of whether it's GHC 8.0 or 8.2. If you tweak `Bug` slightly: {{{#!hs {-# LANGUAGE TypeInType #-} module Bug where import Data.Typeable (Proxy(..), typeRep) import Foo main :: IO () main = print $ typeRep (Proxy :: Proxy MkT) }}} Then it fails on both GHC 8.0 and 8.2 with a similar panic: GHC 8.0: {{{ $ /opt/ghc/8.0.2/bin/runghc Bug.hs GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable $tc'MkT Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initDs IOEnv failure }}} GHC 8.2: {{{ $ /opt/ghc/8.2.1/bin/runghc Bug.hs GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable $tc'MkT Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170623 for x86_64-unknown-linux): initDs }}} So to be honest, I'm not sure how the original program typechecks on GHC 8.0, given the fragility of `MkT`'s `Typeable` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 17:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 17:02:44 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.1a6e8f2a6884559ba268b9e62c1ad6f2@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | TypeFamilies, Typeable 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If you try using `MkT`'s `Typeable` instance in the same module it's defined in, it gets even crazier. This program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Foo where import Data.Typeable (Proxy(..), typeRep) data family T a data instance T Int = MkT main :: IO () main = print $ typeRep (Proxy :: Proxy MkT) }}} Gives the same panic on GHC 8.0.2 and 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/runghc Foo.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170623 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing $tc'MkT which was lazily initialized by mkDsEnvs, I tried to tie the knot, but I couldn't find $tc'MkT in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [a1Vr :-> Identifier ‘$dShow_a1Vr’, a218 :-> Identifier ‘$dTypeable_a218’, r1qQ :-> Type constructor ‘T’, r1rU :-> Data constructor ‘MkT’, r1rV :-> Identifier ‘main’, r1uL :-> Identifier ‘$tcT’, r1v7 :-> Type constructor ‘R:TInt’, r1vc :-> Coercion axiom ‘D:R:TInt0’, r1vg :-> Identifier ‘$WMkT’, r1vh :-> Identifier ‘MkT’, r21e :-> Identifier ‘$trModule’] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1689:23 in ghc:TcIface }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 17:56:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 17:56:19 -0000 Subject: [GHC] #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" In-Reply-To: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> References: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> Message-ID: <059.b9ee7cb4be4b8164336ae3cd6e460ec0@haskell.org> #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, slyfox )]]:\\ >Why take preference of packages coming with ghc in this case?\\ Because these are the main libraries, of course. Those related to Haskell standard Prelude. (e.g Data.Char, Control.Applicative, Control.Monad, Data.Monoid, Data.Foldable and so on)\\\\ >It's not always the case that user wants to use base's primitives.\\ so what?\\\\ >I would say suggesting incorrect module imports would lead to more confusion.\\ You do not trust the compiler?\\ Dr. Bjarne Stroustrup said that you should always trust the answers given by the compiler. And he's right. So that GHC gives the right answers, you have to program it in this way. it is obvious.\\ If the compiler is able to recognize the variables that belong to a module ( which I quote above) it must be able to suggest the appropriate module.\\ __And to go further if the compiler is able to suggest the right module it must be able to compile it independently of the programmer.__\\ The compiler is able to recognize many of the leading pragmas (file-header LANGUAGE pragmas). Experiencing yourself by writing a few expressions that need their pragmas to work, but do not write them and compile the file. You will be surprised to see how well the compiler is able to recognize them and to propose them to the programmer to insert them in the program. Even changes the order of the functions in the file. Moves the first function to the end for example and writes the function from end to beginning. Done with functions using various pragmas and you will be even more surprised.\\ __What the compiler can do is marvellous.__\\\\ >Which procedure should define which packages (and modules) are blessed to deliver suggestions for symbols?\\ I do not quite understand the question.\\ But if you talk about the code that makes it work it would be the same procedure which defines the pragmas I suppose or another choice that remains to be defined.\\\\ >As ticket's subject is worded why Control.Concurrent and Control.Exception should be threated special?\\ Not at all. These modules are examples. The subject is badly defined in the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 19:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 19:50:44 -0000 Subject: [GHC] #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" In-Reply-To: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> References: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> Message-ID: <059.40eedcf9d132b9ac44e1f5de5a0f8342@haskell.org> #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:5 vanto]: > Replying to [[span(style=color: #FF0000, slyfox )]]:\\ > >Why take preference of packages coming with ghc in this case?\\ > Because these are the main libraries, of course. Those related to Haskell standard Prelude. (e.g Data.Char, Control.Applicative, Control.Monad, Data.Monoid, Data.Foldable and so on)\\\\ These functions are not in haskell's (nor in GHC's) Prelude module. Otherwise you would get a working program instead of errors about missing symbols. Let's pick a simple example: **fromList**. Which module(s) should GHC suggest for these? > >It's not always the case that user wants to use base's primitives.\\ > so what?\\\\ It meas that suggestion will not be correct and will mislead user to add wrong module into imports instead of stating the fact about missing import. > >I would say suggesting incorrect module imports would lead to more confusion.\\ > You do not trust the compiler?\\ > Dr. Bjarne Stroustrup said that you should always trust the answers given by the compiler. And he's right. So that GHC gives the right answers, you have to program it in this way. it is obvious.\\ > If the compiler is able to recognize the variables that belong to a module ( which I quote above) it must be able to suggest the appropriate module.\\ > __And to go further if the compiler is able to suggest the right module it must be able to compile it independently of the programmer.__\\ > The compiler is able to recognize many of the leading pragmas (file- header LANGUAGE pragmas). > > Experiencing yourself by writing a few expressions that need their pragmas to work, but do not write them and compile the file. > You will be surprised to see how well the compiler is able to recognize them and to propose them to the programmer to insert them in the program. > Even changes the order of the functions in the file. Moves the first function to the end for example and writes the function from end to beginning. Done with functions using various pragmas and you will be even more surprised.\\ > __What the compiler can do is marvellous.__\\\\ In order to earn user's trust compiler should have minimum of false positives. Missing LANGUAGE pragma detection works differently from symbol resolution. GHC already knows all the syntax it can parse. The lexer branches guarded by LANGUAGE pragmas have conditional code of either parsing expressions correctly or reporting an error about missing LANGUAGE pragma. Even that simple idea and implementation does not always work correctly due to language extensions having a syntactic overlap. > >Which procedure should define which packages (and modules) are blessed to deliver suggestions for symbols?\\ > I do not quite understand the question.\\ > But if you talk about the code that makes it work it would be the same procedure which defines the pragmas I suppose or another choice that remains to be defined.\\\\ LANGUAGE pragma detection does not require loading modules not used by the program. Suggesting symbols would require such loading. The question is about list of such autoloaded modules. > >As ticket's subject is worded why Control.Concurrent and Control.Exception should be threated special?\\ > Not at all. These modules are examples. The subject is badly defined in the ticket. Please reword the ticket description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 20:09:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 20:09:59 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults Message-ID: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Keywords: optimization | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough, and I must explicitly begin the Bracket module with `{-# OPTIONS_GHC -O0 #-}` -- however, that may be due to stack or some other build tool. The main logic which fails is in Bracket.hs, which provides an api to convert bracket-like environment handlers (those with open/close capabilities) to caches which you can run concurrent actions against. The API allows two types of limit on the number of concurrent environments - a `Lax` limit, which will spin up additional connections if none are available, and a `Hard` limit, which caps the environment count. This seems like a detail, but if I remove the `Lax` option (as in BracketOneType), the bug goes away. With both options present, both options manifest the bug. The main.hs module is just a toy program aimed at this api, where we write 1000 lines split to arbitrary files (in a `__dir` specified on the top line - set to tmp). None of this code is important - the actual use case (which fails) is handling multiple concurrent connections to a database. The other programs (mainList, mainOneModule, and mainOneType) all appear to run correctly, and represent my attempts to create minimal cases. In particular, these respectively replace Vector with List, move all code into a single module, and get rid of the multiple options for cache types. The modules should all be the same modulo imports (or inlining) of different `Bracket` modules. I have replicated the bug on Linux, Windows, and Windows Creator Update, all with their respective versions of GHC-8.0.2. The code fails for at least vector-0.11.0.0 and vector-0.12.0.1. NB: There are times with the database access example where, worse than crashing, the program will simply return bad results. I think this might have to do with the laziness of `withEnv`, and our production version uses NFData to deepseq arguments before returning the environment to the cache - that was omitted in this test case for simplicity's sake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 2 20:11:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Jul 2017 20:11:08 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.92f6f0b247943f593659a4e29f57a132@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by newthin): * Attachment "O2failurereplication.tar" added. 4 programs, one of which (main.hs) fails when compiled with optimizations -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 00:38:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 00:38:01 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.c25167f07cbd81b727dc58b35b22148d@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): That's fine for [https://www.reddit.com/r/haskell/comments/6ksr76/rfc_part_1_deriving_instances_of/ what I'm doing], but what is the newtype used for now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 00:54:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 00:54:12 -0000 Subject: [GHC] #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable (was: ANN pragmas and -static fails to compile if dynamic library unavailable) In-Reply-To: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> References: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> Message-ID: <058.2dd5e4dfd5de0c717fd8daacb48ce1ee@haskell.org> #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- @@ -1,2 +1,5 @@ - A Haskell source file with an ANN pragma will fail to compile with -static - if any packages do not have dynamic libraries installed. + An annotation pragma is similar to template haskell in that type-checking + it necessitates loading code into ghci. This means that if any package + dependency does not have a ghci library available, or if the annotation + payload's type is defined in a module that does not have a .dyn_o + available, then type-checking will fail. @@ -4,1 +7,8 @@ - Reproduction: + This problem manifests when compiling with -fno-code as .dyn_o files are + not usually generated. -fno-code does enable object file generation for + modules needed by template haskell(in --make mode), however this same + approach cannot be easily extended to annotations because there is no + annotations language extension. + + Here is a reproduction of the missing dynamic library issue: + @@ -20,2 +30,0 @@ - Presumably the ANN pragma causes ghci to load with all libraries which - must be dynamic. @@ -23,1 +31,10 @@ - Not sure which category is correct for Type of failure. + Note that this fails even though no module of the dependency is imported. + This is especially vexing since, to my knowledge, most annotations in + libraries are simple strings for HLint, which could easily be typechecked + if ghci didn't try to load libraries it didn't need.. + + I suggest the following fixes: + * Do not fail typechecking if an annotation fails in ghci, instead issue a + warning. Possibly suppress this warning by default in -fno-code + * Load libraries in ghci more lazily, or don't bail out in ghci until a + missing library is needed,. New description: An annotation pragma is similar to template haskell in that type-checking it necessitates loading code into ghci. This means that if any package dependency does not have a ghci library available, or if the annotation payload's type is defined in a module that does not have a .dyn_o available, then type-checking will fail. This problem manifests when compiling with -fno-code as .dyn_o files are not usually generated. -fno-code does enable object file generation for modules needed by template haskell(in --make mode), however this same approach cannot be easily extended to annotations because there is no annotations language extension. Here is a reproduction of the missing dynamic library issue: {{{ $ echo "module Bug where {-# ANN module \"just a string\" #-}" > Bug.hs $ cabal sandbox init $ cabal install transformers-compat --disable-shared $ ghc -static -package db ./.cabal-sandbox/x86_64-linux- ghc-8.2.0.20170522-packages.conf.d -package transformers-compat -c Bug.hs : can't load .so/.DLL for: libHStransformers- compat-0.5.1.4-DQiwI4tzfvoKHf8rERr8Q2.so (libHStransformers- compat-0.5.1.4-DQiwI4tzfvoKHf8rERr8Q2.so: cannot open shared object file: No such file or directory) $ cabal install transformers-compat --enable-shared --reinstall $ ghc -static -package db ./.cabal-sandbox/x86_64-linux- ghc-8.2.0.20170522-packages.conf.d -package transformers-compat -c Bug.hs -fforce-recomp }}} Note that this fails even though no module of the dependency is imported. This is especially vexing since, to my knowledge, most annotations in libraries are simple strings for HLint, which could easily be typechecked if ghci didn't try to load libraries it didn't need.. I suggest the following fixes: * Do not fail typechecking if an annotation fails in ghci, instead issue a warning. Possibly suppress this warning by default in -fno-code * Load libraries in ghci more lazily, or don't bail out in ghci until a missing library is needed,. -- Comment (by duog): Reword and generalize to include problems with -fno-code. Let me know if my solutions sound reasonable, I am happy to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 02:10:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 02:10:49 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.56a723a2b2646cbe83e486ce5c4e0310@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3619 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > How does ​Phab:D3682 look? It's good, thank you Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 02:41:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 02:41:24 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.11766f25801574604ff4febd5b7cd497@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, this looks quite bad indeed. Thanks for providing such a nice reproducer! `gdb` places the crash in, {{{ Program received signal SIGSEGV, Segmentation fault. stg_takeMVarzh () at rts/PrimOps.cmm:1483 1483 rts/PrimOps.cmm: No such file or directory. (gdb) bt #0 stg_takeMVarzh () at rts/PrimOps.cmm:1483 #1 0x000000000064dc88 in base_GHCziIOziHandleziInternals_zdwdozuoperation_info () at libraries/base/GHC/IO/Handle/Internals.hs:163 #2 0x0000000000646ce0 in sb1n_info () at libraries/base/GHC/IO/Handle.hs:470 #3 0x0000000000407378 in s6zq_info () at ./Bracket.hs:105 #4 0x0000000000613e58 in s3E1_info () at libraries/base/Control/Exception/Base.hs:222 #5 0x00000000006e75f0 in ?? () #6 0x000000000040a328 in sdbc_info () at main.hs:21 #7 0x0000000000454680 in sbFu_info () #8 0x0000000000000000 in ?? () }}} The disassembly of the top frame is, {{{ (gdb) disassemble Dump of assembler code for function stg_takeMVarzh: 0x00000000006ebd70 <+0>: mov (%rbx),%rax 0x00000000006ebd73 <+3>: cmpq $0x94f088,0x18(%rbx) 0x00000000006ebd7b <+11>: je 0x6ebe97 0x00000000006ebd81 <+17>: mov %rbx,%rcx 0x00000000006ebd84 <+20>: mov 0x18(%rbx),%rdx 0x00000000006ebd88 <+24>: mov 0x8(%rbx),%rbx 0x00000000006ebd8c <+28>: cmp $0x94f088,%rbx 0x00000000006ebd93 <+35>: je 0x6ebe56 => 0x00000000006ebd99 <+41>: cmpq $0x6ecf30,(%rbx) 0x00000000006ebda0 <+48>: je 0x6ebe4d ... }}} Where 0x6ecf30 is apparently `stg_IND_info`. This likely means that we are approximately here in `stg_takeMVarzh`, {{{#!c ... loop: if (q == stg_END_TSO_QUEUE_closure) { /* No further putMVars, MVar is now empty */ StgMVar_value(mvar) = stg_END_TSO_QUEUE_closure; // If the MVar is not already dirty, then we don't need to make // it dirty, as it is empty with nothing blocking on it. unlockClosure(mvar, info); return (val); } if (StgHeader_info(q) == stg_IND_info || /* <- perhaps here */ StgHeader_info(q) == stg_MSG_NULL_info) { q = StgInd_indirectee(q); goto loop; } ... }}} The value of `$rbx` looks quite crazy, {{{ (gdb) print $rbx $1 = 5283285312859013268 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 02:48:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 02:48:52 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.44a64cd06a0029f67c95c35107fb6e27@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well this may be odd. When `stg_takeMVarzh` is called `$rax` contains a pointer to a `CATCH_RETRY_FRAME`. I've hiked more miles than I can count on my fingers today, so I'll need to drop this here and get some sleep. However, I'll be back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 02:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 02:56:59 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.682f344b432e8aae22dc721d5a17513d@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One last observation: it looks like this `CATCH_RETRY_FRAME` was (perhaps as expected) constructed by `stg_catchRetryzh`, {{{ (rr) bt #0 0x00000000006eb879 in stg_catchRetryzh () at rts/PrimOps.cmm:1245 #1 0x00000000006eb408 in ?? () at rts/PrimOps.cmm:990 #2 0x00000000004073a0 in s6zq_info () at ./Bracket.hs:105 #3 0x0000000000613e58 in s3E1_info () at libraries/base/Control/Exception/Base.hs:222 #4 0x00000000006e75f0 in ?? () #5 0x000000000040a328 in sdbc_info () at main.hs:21 #6 0x0000000000454680 in sbFu_info () #7 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 03:39:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 03:39:43 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.b1a5abc79b0ed8e7a697255f6b9a7ad2@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): I might have a use case for this, but I’m not smart enough to understand if my problem would be solved by this feature or not. Basically, I have a type family for type-level append: {{{ #!hs type family xs :++: ys where '[] :++: ys = ys (x ': xs) :++: ys = x ': (xs :++: ys) }}} This family is not injective, but if you know the result and one of the two inputs, you can deduce the other one. Therefore, I would like to be able to write the dependency annotation `r xs -> ys, r ys -> xs`. I have written a function that uses `:++:` in its type signature, which currently looks like this: {{{ #!hs forall g r a f. (forall v. f v -> Eff (g :++: r) v) -> Eff (f ': r) a -> Eff (g :++: r) a }}} Currently, this signature is ambiguous. However, notably, we know `r`, and in the location this function is used, we also know `g :++: r`. Therefore, my hope is that with this feature, I could use this function, and `g` could be inferred. Currently, however, I have to use `TypeApplications` to pick `g` explicitly, even though the type seems “obvious” to the programmer at its use site (since it very explicitly duplicates type information in an adjacent top-level annotation). I don’t know enough to know if such an annotation would actually allow such a thing or not, or if this is even applicable in my use case, but I thought I would offer the example anyway, since it sounds like this feature is in need of motivating examples. (I can also try and come up with a smaller, self-contained example if I’m not totally off base and that would, in fact, be relevant/helpful.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 05:33:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 05:33:21 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.8a4b539915dc08c6cb19e745c901aa4c@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 05:38:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 05:38:09 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.61c1f14f89d9eec089f5ddaab8edc532@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): It's useful since you often want to define `(<*>)` in terms of `(>>=)`. I'm putting this in a distinct category of retrofitted things from defining `return` from `pure`, since the latter is completely trivial (`return = pure`), whereas the former requires a tad more work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 07:44:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 07:44:29 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.46f3efa0c25ce2249b893eb1e7f95ca9@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The code you point to implements `MVar`s. The example code doesn't seem to handle any of those directly. The only `MVar`s I see in the vicinity are in `async`, and there don't seem to be any arrays around there to index improperly. Specifically, `forConcurrently_` (used in `main.hs`) is ultimately defined in terms of `concurrently`, which uses an `MVar`. But that doesn't bring any potentially-dangerous vector indexes close enough to make those look like good candidates for the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 08:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 08:10:43 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.1dfce485aa5c78990d426f336fb5a57b@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:13 looks like a use-case for injectivity to me. comment:9 has a fairly well-advanced implementation, just needs completing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 08:57:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 08:57:12 -0000 Subject: [GHC] #13906: ApplicativeDo doesn't handle existentials as well as it could In-Reply-To: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> References: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> Message-ID: <060.4bc535b82a4050be9267f9cf617aac52@haskell.org> #13906: ApplicativeDo doesn't handle existentials as well as it could -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ApplicativeDo 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: | -------------------------------------+------------------------------------- Comment (by simonmar): Right, but we only need to ensure that a strict pattern match is bound by a `>>=`. In my example: {{{ do T x1 <- a x2 <- b x1 T x2 <- c x4 <- d x2 return (x2,x4) }}} we can safely translate this to: {{{ (\x2 x4 -> (x2,x4)) <$> (a >>= \(T x1) -> b x1) <*> (c >>= \(T x2) -> d x2) }}} and this has the correct strictness behaviour. I won't write it all out here, but I'm sure you can see that if you expand out using `<*> = ap` and apply some other laws then you'll get the right sequence of binds here. This translation is better (i.e. has lower cost, in the terminology of the ApplicativeDo paper) than the one we'd get if we just started by breaking up the original sequence at every strict pattern match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 09:51:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 09:51:18 -0000 Subject: [GHC] #13906: ApplicativeDo doesn't handle existentials as well as it could In-Reply-To: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> References: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> Message-ID: <060.034591a89333251c0e6e3d28042a0110@haskell.org> #13906: ApplicativeDo doesn't handle existentials as well as it could -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ApplicativeDo 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Doesn't #13875 make all this moot? All patterns binding existentils are srtrict, so (in my imperfect undersatnding) we have to do a monadic bind, at the expense of parallelism, but making it straightforward to keep existentials in scope. I'm beginning to think that an update of the paper, covering strict patterns and existentials in the vocabulary and notation of the paper, would be a good investment. I'm getting lost! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 10:09:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 10:09:13 -0000 Subject: [GHC] #13893: Improved help for "import" command at the start of a script when "variable not in scope" in error msg (was: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope") In-Reply-To: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> References: <044.50a1c8e97ad1d72587a33a02855fe4cb@haskell.org> Message-ID: <059.51bf34fc72c851194b402c2a8b210e9c@haskell.org> #13893: Improved help for "import" command at the start of a script when "variable not in scope" in error msg -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, slyfox )]]\\ To make it simple: {{{ module Azer where -- import Data.Char main :: IO () main = print (map toLower "HELLO") }}} Compiler response:\\ {{{ Prelude> :l azer [1 of 1] Compiling Azer ( azer.hs, interpreted ) azer.hs:5:19: error: Variable not in scope: toLower :: Char -> b0 | 5 | main = print (map toLower "HELLO") | ^^^^^^^ Failed, modules loaded: none. }}} {{{toLower}}} belongs to data. Char. It would be easy for GHC to propose it in suggestion. How? I do not know. I have not the same knowledge as you in the Haskell compiler. Nevertheless I think that is possible. Easy or difficult to do, I don't know.\\ Regarding FromList, for instance:\\ {{{ Data.Sequence.fromList :: [a] -> Seq a -- Defined in `Data.Sequence' Data.IntSet.fromList :: [Key] -> IntSet -- Defined in `containers-0.5.7.1:Data.IntSet.Base' }}} It may be more difficult. We can teach the compiler to make a better difference.\\ How? I do not know yet but it can be studied.\\ This ticket should be considered as an idea for a future improvement in aid to the programmer.\\ Nevertheless as many people agree to improve the error messages, and this for a very long time, it is certainly better to start thinking about this. As this ticket is part of it, it will be de facto taken into account. Don't worry too much with this ticket, consider it only as an idea that can be applied later in the compiler. Do not close this ticket it will be able to serve later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 10:25:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 10:25:51 -0000 Subject: [GHC] #13905: ApplicativeDo is too strict with newtype patterns In-Reply-To: <045.00a8d56ab6c9231b9decf90394137e4f@haskell.org> References: <045.00a8d56ab6c9231b9decf90394137e4f@haskell.org> Message-ID: <060.634fb3e7503f90837d37ad57cf6a4352@haskell.org> #13905: ApplicativeDo is too strict with newtype patterns -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): That is extremely annoying, and so clearly an artefact of GHC's architecture, rather than any solid reason, that we should question it. For example we could 1. Keep track in the renamer of what local data constructors are newtypes. (We already know this for imported ones.) 2. Rename and typecheck all data/class decls before we even start on the value declarations. A bit like we do for top-level Template Haskell splices. The second of these looks more solid to me. I recall that there's a similar issue with record fields, when the renamer wants to know what fields a particular data constructor has. Currently we use a variant of (1) I think; but (2) would solve it and thereby simplify that code. So I quite like (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 11:02:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 11:02:33 -0000 Subject: [GHC] #13905: ApplicativeDo is too strict with newtype patterns In-Reply-To: <045.00a8d56ab6c9231b9decf90394137e4f@haskell.org> References: <045.00a8d56ab6c9231b9decf90394137e4f@haskell.org> Message-ID: <060.fbf714294f2d1a3f3780b51125c7f5b0@haskell.org> #13905: ApplicativeDo is too strict with newtype patterns -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: ApplicativeDo 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 11:07:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 11:07:50 -0000 Subject: [GHC] #3205: Generalized isomorphic deriving In-Reply-To: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> References: <042.5465e02313ec0c86ef0c59c5b9869960@haskell.org> Message-ID: <057.8d5a2418119d9ace41117510faa5b3f2@haskell.org> #3205: Generalized isomorphic deriving -------------------------------------+------------------------------------- Reporter: ajd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: language Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 11:33:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 11:33:55 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.a089a629c8b00b52e0f581cdfe989ba9@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm really not sure about this. Mutable arrays have ''identity'' so it makes sense to ask if they are "the same". Immutable arrays do not. Are the two lists `[2,3]` and `[2,3]` "the same"? Would it make a difference if you let-bound it `let x = [2,3] in sameList x x`? We have `unsafePtrEq` and `reallyUnsafePtrEq`. Maybe use them instead? The danger is that legitimate compiler optimisations might change behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 12:28:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 12:28:01 -0000 Subject: [GHC] #13906: ApplicativeDo doesn't handle existentials as well as it could In-Reply-To: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> References: <045.7a2a5b8fd2cc16f87e0125054276df67@haskell.org> Message-ID: <060.58ed1c431090b5da21a149cd10fc4bcc@haskell.org> #13906: ApplicativeDo doesn't handle existentials as well as it could -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ApplicativeDo 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 simonmar]: > Right, but we only need to ensure that a strict pattern match is bound by a `>>=`. Ah, now I see what you're saying! I was misled by the fact that `b` and `d` are applied to `x1` and `x2`. What you were getting at is that by simply making the very next action "dependent" on a strict pattern match, you propagate strictness from the result level to the action level and rely on the fact that strict monads have `undefined *> a = undefined`. Does that hold up for reader, for example? It doesn't for lazy `State`, but the latter isn't strictly law-abiding, so you're in the clear there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 13:30:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 13:30:36 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.24a729d6e0dcbf3da051f5fa70303e51@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > The code you point to implements MVars. The example code doesn't seem to handle any of those directly. Look again at the stacktrace. The `MVar`s involved are those in GHC's `Handle` implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 13:35:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 13:35:26 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.16066c50287bd5a8c846cf7f91941808@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 13:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 13:43:46 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.57b8de36d4fe2db7604b374d7cc9fd8e@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => wontfix @@ -8,1 +8,1 @@ - {{{ + {{{#!hs New description: Sometime it is useful to compare reference equality for immutable arrays, for example when comparing vectors which are slices of arrays, we may want to know if two vectors are slices of the same array. But currently we only have `sameMutableXXXArray` primitives. A workaround may look like this: {{{#!hs sameArray :: Array a -> Array a -> Bool sameArray arr1 arr2 = runST (do marr1 <- unsafeThawArray arr1 marr2 <- unsafeThawArray arr2 return (sameMutableArray marr1 marr2) ) }}} But the problem is for boxed arrays, this code will push an unchanged array to mutable list if it's already on older generations. Next GC will have to scan it(at least will scan its card table). I can see two solutions here, first one is to add `sameXXXArray` for all array types. The second one is somehow more complex: Currently we simply rewrite array's header to `MUT_ARR_PTRS_FROZEN0/SMALL_MUT_ARR_PTRS_FROZEN0` when we do `unsafeFreeze`. But for mutable array with no write happend, e.g. the ones with `MUT_ARR_PTRS_CLEAN/SMALL_MUT_ARR_PTRS_CLEAN` header. we can safely rewrite the header to `MUT_ARR_PTRS_FROZEN/SMALL_MUT_ARR_PTRS_FROZEN`, so that we can keep it from next GC. Then to fix previous code, we can add a freeze before returning. Of course we can do these two solutions all together ; ) -- Comment: > Mutable arrays have identity so it makes sense to ask if they are "the same". That is a fair point. I suppose this is a sensible reason for this asymmetry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 14:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 14:16:25 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.09eaff36141e2c59bfe84a0985fdf491@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't have bandwidth to reproduce right now, but I think Matthew is saying we have {{{ f :: forall s. State# s -> blah f = /\s. \(x::State# s). ....(g @s d1 d2 d3).... }}} where `g` is an overloaded function, called three dictionary arguments. But note that `f` is not overloaded, and so will not be auto-specialised. Somehow, if we specialised `f`, we could specialise `g`. I don't quite see how this happens. Can you fill in a bit more detail about what `g` is, and what dictionaries `d1`-`d3` are? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 14:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 14:41:52 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.2370bbc5b86663e751de69b142285bc7@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): David will summarise by saying * Compile this module X with these flags * Compiler allocations (a) pre offending patch (b) post offending patch (c) HEAD * Tidy Core sizes for (a)-(c); i.e. is it slower because we are compiling more code or because we are taking long to compile it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 14:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 14:47:26 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.0ace54fc93f1e2821cf286dfb33b450e@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Comment (by mpickering): That's right Simon. How this happens is that the `SPECIALISE` pragma creates a rule which looks like {{{ "SPEC insertWith" forall (@ k) (@ s) (@ v) ($dHashable :: Hashable k) ($dEq :: Eq k) ($dPrimMonad :: PrimMonad (ST s)). insertWith @ k @ (ST s) @ v $dHashable $dEq $dPrimMonad = $sinsertWith @ k @ s @ v $dHashable $dEq }}} which fires at quite an early stage in optimisation. Then any function in `$sinsertWith` which mentions `s` won't be specialised as it is lambda bound. If you remove the pragma you just get one specialisation rule which probably arises after a lot of inlining has happened. {{{ "SPEC/Main insert @ ByteString @ (ST RealWorld) _" forall (@ v) ($dPrimMonad :: PrimMonad (ST RealWorld)) ($dEq :: Eq ByteString) ($dHashable :: Hashable ByteString). insert @ ByteString @ (ST RealWorld) @ v $dHashable $dEq $dPrimMonad = $scheckResize_$sinsert @ v }}} and if you fix `s = RealWorld` with the specialisation pragma then both occur. {{{ "SPEC insertWith" forall (@ k) (@ v) ($dHashable :: Hashable k) ($dEq :: Eq k) ($dPrimMonad :: PrimMonad (ST RealWorld)). insertWith @ k @ (ST RealWorld) @ v $dHashable $dEq $dPrimMonad = $sinsertWith @ k @ v $dHashable $dEq "SPEC/Main insert @ ByteString @ (ST RealWorld) _" forall (@ v) ($dPrimMonad :: PrimMonad (ST RealWorld)) ($dEq :: Eq ByteString) ($dHashable :: Hashable ByteString). insert @ ByteString @ (ST RealWorld) @ v $dHashable $dEq $dPrimMonad = $scheckResize_$sinsert @ v }}} Seeing as you also ask for the type of `g`, it is defined in another module as is marked `INLINABLE`. {{{ checkResize::(Hashable k,Eq k,PrimMonad m) => HashTable_ (PrimState m) k v -> m (Maybe (HashTable (PrimState m) k v)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 14:49:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 14:49:40 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.559e530e825c0b4069dc48ffde23ead5@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:4 jberryman]: > Thanks so much for looking into this. I maybe wasn't clear in the body that the reason I filed the ticket was I assumed that GHC would try to choose the best specialization from those in scope (since my intuition was specialize pragmas behave sort of like type classes in the way they leak via `import` statements) and from whatever specializations it might perform in context. > > But maybe this is expected behavior, and a manual specialization will always take precedence? The specialiser doesn't choose which specialisation to apply, it merely looks for specialisation opportunities and then creates a new definition along with a RULE which does the replacement. If you have conflicting specialisations then the choice about which one applies is left up to he rule selection mechanism which I am not as familiar with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 14:58:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 14:58:43 -0000 Subject: [GHC] #13894: isByteArrayPinned# should consider BF_LARGE In-Reply-To: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> References: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> Message-ID: <060.69707c2a707acdc3b114f0616968782b@haskell.org> #13894: isByteArrayPinned# should consider BF_LARGE -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3685 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.1 Comment: Winter requested that we sneak this in to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 15:00:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 15:00:02 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.7d94548d79bf62624ef5f8374f4f3f1a@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | 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): Phab:D3584 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 15:27:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 15:27:35 -0000 Subject: [GHC] #10648: Some 64-vector SIMD primitives are absolutely useless In-Reply-To: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> References: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> Message-ID: <059.440bee9724ad6dddbea51277dc33e620@haskell.org> #10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: SIMD 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: | -------------------------------------+------------------------------------- Changes (by carter): * cc: carter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 15:27:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 15:27:51 -0000 Subject: [GHC] #10648: Some 64-vector SIMD primitives are absolutely useless In-Reply-To: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> References: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> Message-ID: <059.791808c79678ba47a47d597f09cff84b@haskell.org> #10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: SIMD 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: | -------------------------------------+------------------------------------- Changes (by Axman6): * cc: carter (removed) * cc: Axman6 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 15:28:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 15:28:02 -0000 Subject: [GHC] #10648: Some 64-vector SIMD primitives are absolutely useless In-Reply-To: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> References: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> Message-ID: <059.fcde3f17fd909d2dcd0c6dadf8d5da61@haskell.org> #10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: SIMD 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: | -------------------------------------+------------------------------------- Changes (by Axman6): * cc: carter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 16:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 16:03:39 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.0892fe0e117e2ada529660ee7fb4c26d@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Sounds reasonable. I will go with unsafeCoerce#. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 17:13:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 17:13:06 -0000 Subject: [GHC] #10648: Some 64-vector SIMD primitives are absolutely useless In-Reply-To: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> References: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> Message-ID: <059.7e20e416e45dc8a7e8aa7bf5908831fd@haskell.org> #10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: SIMD 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: | -------------------------------------+------------------------------------- Comment (by bgamari): An easy way to resolve this would be to bump the maximum tuple width to 64. I don't know precisely what this would involve, but I doubt it would be very difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 18:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 18:53:08 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. Message-ID: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- {{{ module Qwer where a = {-# LANGUAGE KindSignatures #-} main :: IO () main = print (if True then () else ()) }}} Reply from GHC\\ {{{ Prelude> :l qwer.hs [1 of 1] Compiling Qwer ( qwer.hs, interpreted ) qwer.hs:5:1: error: parse error (possibly incorrect indentation or mismatched brackets) | 5 | main :: IO () | ^ Failed, modules loaded: none. }}} The error is located on line 3.\\ GHCi, version 8.2.0.20170507 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 19:00:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 19:00:19 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas Message-ID: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- {{{ module Qwer where a = ({-# LANGUAGE #-}) main :: IO () main = print (if True then () else ()) }}} if {{{a = ({-# #-})}}} then GHC compiles with a warning\\ {{{ qwer.hs:3:6: warning: [-Wunrecognised-pragmas] Unrecognised pragma | 3 | a = ({-# #-}) | ^^^ Ok, modules loaded: Qwer. }}} if you write {{{a = ({-# LANGUAGE #-})}}} without writing the name GHC compiles the file without specifying a warning.\\ {{{ *Qwer> :l qwer.hs [1 of 1] Compiling Qwer ( qwer.hs, interpreted ) Ok, modules loaded: Qwer. }}} GHCi, version 8.2.0.20170507 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 19:58:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 19:58:59 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.33a779573210e90ecdc401965c84ce19@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 | -------------------------------------+------------------------------------- Comment (by bgamari): In response to recent interest in SIMD support, I pondered this for a bit while wandering in the woods yesterday. I think there's a pretty straightforward path to introducing SIMD (including AVX) support in the NCG. Here's my proposed plan, * Introduce a few types, {{{#!hs -- | The format of a vector value data VecFormat = VecFormat { vecWidth :: Width -- ^ vector width (e.g. how many scalars?) , vecFormat :: ScalarFormat -- ^ the format of each scalar } -- | What type of quantity is a scalar? data ScalarFormat = FmtInt | FmtFloat -- | The width of a scalar in bits data ScalarWidth = Width8 | Width16 | Width32 | Width64 -- this already exists type Width = Int }}} * Rework the instructions in `nativeGen/X86/Instr.hs` to carry a `VecFormat` instead of a `Format`. Perhaps just start with `ADD` before moving on to the others just to make sure this plan works. * For the purposes for register allocation pretend there are only ZMM registers (e.g. ignoring XMM and YMM). This saves us from having to worry about register aliasing. We can then use the `VecFormat` to determine what kind of register we really mean. I believe this can be done in `nativeGen/X86/Regs.hs:allocatableRegs`. * I think the calling convention logic (e.g. in `cmm/CmmCallConv.hs`) should require no change. * Add the necessary pretty-printing logic (in `nativeGen/X86/Ppr.hs`) to produce the new instructions * Add the necessary logic to the code generator to implement the `MachOps` (e.g. `nativeGen/X86/CodeGen.hs`) All-in-all this seems quite feasible and likely no more than a day or two of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 20:28:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 20:28:32 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.0338df55e77fe00486c2b8262bdc81fd@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by j.waldmann): No. This program (with a change in line 5 onle) is valid: {{{ module Qwer where a = {-# LANGUAGE KindSignatures #-} main :: IO () main = print (if True then () else ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 20:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 20:36:17 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas In-Reply-To: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> References: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> Message-ID: <059.f35d074dac9ee90330b6bb6628f4285e@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by j.waldmann): What do think is the error here? An individual language pragma begins with the keyword LANGUAGE and is followed by a comma-separated list of named language features https://www.haskell.org/onlinereport/haskell2010/haskellch12.html#x19-19100012.3 This list can be empty (it does not say otherwise), so `{-# LANGUAGE #-}` is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 22:58:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 22:58:31 -0000 Subject: [GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 In-Reply-To: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> References: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> Message-ID: <061.d04199bc773538215dcf951ef22775a0@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f9c6d53fe997f1c560cda6f346f4b201711df37c/ghc" f9c6d53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f9c6d53fe997f1c560cda6f346f4b201711df37c" Tag the FUN before making a PAP (#13767) Pointers to FUNs are not guaranteed to be tagged in general, because the compiler doesn't always know the arity of a FUN when it needs to reference it, e.g. with -O0 when the function is in another module. However, there's one case where we can put the correct tag on a FUN: when it is referenced by a PAP, because when building the PAP we know the arity and we can tag the pointer correctly. The AutoApply code does this, and the sanity checker checks it, but the interpreter did not respect this invariant. This patch fixes it. Test Plan: ``` (cd ghc && make 2 GhcDebugged=YES) ./inplace/bin/ghc-stage2 --interpreter +RTS -DS ``` Reviewers: niteria, bgamari, austin, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13767 Differential Revision: https://phabricator.haskell.org/D3680 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 22:58:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 22:58:31 -0000 Subject: [GHC] #13914: -fignore-asserts flag not handled by recompilation checker In-Reply-To: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> References: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> Message-ID: <058.98aad7f179c2b7744a4273753508a99f@haskell.org> #13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3698 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1a9c3c44ef82803766a8db91a619393c43195ad3/ghc" 1a9c3c44/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a9c3c44ef82803766a8db91a619393c43195ad3" Implement recompilation checking for -fignore-asserts Test Plan: Added a test which was previously failing Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13914 Differential Revision: https://phabricator.haskell.org/D3698 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 22:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 22:58:32 -0000 Subject: [GHC] #13863: -fno-code is broken on package:language-c-quote In-Reply-To: <043.24c6df62c4ee22a450d0662d44837518@haskell.org> References: <043.24c6df62c4ee22a450d0662d44837518@haskell.org> Message-ID: <058.87b7678d88ce6977fc78d7a497646edf@haskell.org> #13863: -fno-code is broken on package:language-c-quote -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | quasiquotation/T13863 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d55bea14c745f7f448fb24673a21b511d1c1c222/ghc" d55bea14/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d55bea14c745f7f448fb24673a21b511d1c1c222" Fix -fno-code for modules that use -XQuasiQuotes In commit 53c78be0aab76a3107c4dacbb1d177afacdd37fa object code is generated for modules depended on by modules that use -XTemplateHaskell. This turns the same logic on for modules that use -XQuasiQuotes. A test is added. Note that I've based this of D3646, as it has a function I want to use. Test Plan: ./validate Reviewers: austin, bgamari, alexbiehl Reviewed By: alexbiehl Subscribers: alexbiehl, rwbarton, thomie GHC Trac Issues: #13863 Differential Revision: https://phabricator.haskell.org/D3677 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 22:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 22:58:32 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.9faa1529deccf8993af8d67a55d60f4c@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3678 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c3a78623cf7bb74c8ca0749f1216e802aa37a721/ghc" c3a7862/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c3a78623cf7bb74c8ca0749f1216e802aa37a721" Fix #13311 by using tcSplitNestedSigmaTys in the right place Previously, we we only using `tcSplitSigmaTy` when determining if a function had been applied to too few arguments, so it wouldn't work for functions with nested `forall`s. Thankfully, this is easily fixed with a dash of `tcSplitNestedSigmaTys`. Test Plan: make test TEST=T13311 Reviewers: austin, bgamari, simonpj Reviewed By: bgamari Subscribers: goldfire, simonpj, rwbarton, thomie GHC Trac Issues: #13311 Differential Revision: https://phabricator.haskell.org/D3678 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:26:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:26:28 -0000 Subject: [GHC] #13914: -fignore-asserts flag not handled by recompilation checker In-Reply-To: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> References: <043.c5ecc7b9fb6a139d43a91db3e9b88848@haskell.org> Message-ID: <058.e94accb6f989af5fac42fa6865c75461@haskell.org> #13914: -fignore-asserts flag not handled by recompilation checker -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Driver | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3698 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:26:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:26:44 -0000 Subject: [GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 In-Reply-To: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> References: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> Message-ID: <061.80766b2cfc5908e93fae0cd113922605@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3680 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:26:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:26:53 -0000 Subject: [GHC] #13863: -fno-code is broken on package:language-c-quote In-Reply-To: <043.24c6df62c4ee22a450d0662d44837518@haskell.org> References: <043.24c6df62c4ee22a450d0662d44837518@haskell.org> Message-ID: <058.9686b01900f6a078a2b282e4d075797c@haskell.org> #13863: -fno-code is broken on package:language-c-quote -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | quasiquotation/T13863 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3677 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:45 -0000 Subject: [GHC] #13875: ApplicativeDo desugaring is lazier than standard desugaring In-Reply-To: <045.2eda858359df0999208d04da5f95a1da@haskell.org> References: <045.2eda858359df0999208d04da5f95a1da@haskell.org> Message-ID: <060.8338efd085b7f4da9bc7a99cc898bfdf@haskell.org> #13875: ApplicativeDo desugaring is lazier than standard desugaring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"af403b2eb50abde6a7992470032d7df5faea043e/ghc" af403b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af403b2eb50abde6a7992470032d7df5faea043e" ApplicativeDo: document behaviour with strict patterns (#13875) Test Plan: unit tests, built docs Reviewers: dfeuer, bgamari, simonpj, austin, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13875, #13242 Differential Revision: https://phabricator.haskell.org/D3691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:45 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.b9249c49338c2d76e8f553fa070b3e74@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: ApplicativeDo 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 Ben Gamari ): In [changeset:"af403b2eb50abde6a7992470032d7df5faea043e/ghc" af403b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af403b2eb50abde6a7992470032d7df5faea043e" ApplicativeDo: document behaviour with strict patterns (#13875) Test Plan: unit tests, built docs Reviewers: dfeuer, bgamari, simonpj, austin, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13875, #13242 Differential Revision: https://phabricator.haskell.org/D3691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:45 -0000 Subject: [GHC] #13894: isByteArrayPinned# should consider BF_LARGE In-Reply-To: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> References: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> Message-ID: <060.35d11864423c7965ab1e0f18a6aaca15@haskell.org> #13894: isByteArrayPinned# should consider BF_LARGE -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3685 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a6f3d1b00e9c37a56cd4db9e519309e94a65d181/ghc" a6f3d1b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6f3d1b00e9c37a56cd4db9e519309e94a65d181" rts: Fix isByteArrayPinned#'s treatment of large arrays It should respond with True to both BF_PINNED and BF_LARGE byte arrays. However, previously it would only check the BF_PINNED flag. Test Plan: Validate Reviewers: simonmar, austin, erikd Subscribers: winterland1989, rwbarton, thomie GHC Trac Issues: #13894 Differential Revision: https://phabricator.haskell.org/D3685 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:46 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.28ba9a7e64b3ca0cad2748e3317e2309@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13810, #13739 | Differential Rev(s): Phab:D3449, Wiki Page: | Phab:D3694 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"960918bd1f7e3811845a525ba85bbd390ddf28c8/ghc" 960918bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="960918bd1f7e3811845a525ba85bbd390ddf28c8" Add -fuse-ld flag to CFLAGS during configure The decisions made by configure later in the script may depend upon the linker used. Consequently, it is important that configure uses the same linker as GHC will eventually use. For instance, on Nix I found that a program requiring `libpthread` would link fine with only `-lrt` when linked with BFD ld. However, with gold we needed to explicitly provide the `-lpthread` dependency. Presumably the former would happily loaded any `NEEDED` libraries whereas the latter wants them explicitly given. Regardless, since `configure`'s `NEED_PTHREAD_LIB` check didn't use the `-fuse-ld` flag that GHC would eventually use, we inferred the wrong value, resulting in link errors later in the build. Test Plan: Validate Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13541 Differential Revision: https://phabricator.haskell.org/D3694 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:46 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.883d76e6b57d52ffabc964fe7656fd18@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0836bfbd480b00a690937060fc98df5e26453078/ghc" 0836bfb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0836bfbd480b00a690937060fc98df5e26453078" testsuite: Add testcase for #13615 Reviewers: austin Subscribers: dfeuer, rwbarton, thomie GHC Trac Issues: #13615 Differential Revision: https://phabricator.haskell.org/D3696 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 3 23:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Jul 2017 23:42:46 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.fc14844b16a2a3dae36b7d2843d3d4d8@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fd7a7a6363d8dde1813bc23cb4ef00ebb70a49c0/ghc" fd7a7a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd7a7a6363d8dde1813bc23cb4ef00ebb70a49c0" Eagerly blackhole AP_STACKs This fixes #13615. See the rather lengthy Note [AP_STACKs must be eagerly blackholed] for details. Reviewers: simonmar, austin, erikd, dfeuer Subscribers: duog, dfeuer, hsyl20, rwbarton, thomie GHC Trac Issues: #13615 Differential Revision: https://phabricator.haskell.org/D3695 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 00:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 00:18:57 -0000 Subject: [GHC] #13894: isByteArrayPinned# should consider BF_LARGE In-Reply-To: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> References: <045.c57512fc5db0ab6f4b4f6b7f8600318c@haskell.org> Message-ID: <060.a107ac1277edf3af0b8e0b779aeb4379@haskell.org> #13894: isByteArrayPinned# should consider BF_LARGE -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3685 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 32dd9b8b84dfc2a395551f38bc3f1c8b470a2eb9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 00:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 00:20:48 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.c402e4a5681c83ac0f977ec29d08223b@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13810, #13739 | Differential Rev(s): Phab:D3449, Wiki Page: | Phab:D3694 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 0798908f1729629c2d90a56baae06919874b42a4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 00:21:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 00:21:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.c791ff6bc0a77dbaede6a66a11af4e99@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with d94aebd369a78ae55ab2c078da79e4dc11fa9657 and c1c0985416a6f9766c03d361449f556905bf8e1d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 05:30:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 05:30:00 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.7f09f5bf61581df4d8372eabd7216a71@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 | -------------------------------------+------------------------------------- Comment (by winter): Wow, this is a good news! One thing makes situation complicated is that there're several versions of SIMD implementations out there(SSE4, AVX, AVX2...), and we seems don't have a clear plan to support which version, or provide user compile flag to do fallback. After thinking about this over. I think we'd be better split SIMD primitive into `GHC.Prim.SSE4`, `GHC.PrimAVX` modules to avoid this compatibility hell. Compiler should be able to produce whatever instructions programmer want it to. We also have to provide runtime detections in RTS, use some unsafe magic we should be able to provide SIMD supporting conditions as constants. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 09:06:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 09:06:06 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.143f39e9341384e8a7fb52e6080843ee@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1185 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is this needed now that we have visible type application -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 09:25:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 09:25:27 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas In-Reply-To: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> References: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> Message-ID: <059.73717a747802ccffbd4ea0b955d572aa@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, j.waldmann )]]\\ >This list can be empty\\ About LANGUAGE pragma, Can you quote the reference manual in which you read this sentence, please, and show me the page? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 09:57:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 09:57:27 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.5db8bc45cec32d0a76eabae187b9ae5f@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, j.waldmann )]]\\ Interesting! I can do better.\\ {{{ module Qwer where a = ({-# LANGUAGE KindSignatures #-}) main :: IO () main = print (if True then () else ()) }}} One more thing. If I change your code like that\\ {{{ module Qwer where a = ({-# LANGUAGE KindSignatures #-}) main :: IO () main = print (if True then () else ()) }}} GHC says\\ {{{ Prelude> :l qwer.hs [1 of 1] Compiling Qwer ( qwer.hs, interpreted ) qwer.hs:3:5: error: * Couldn't match expected type `IO () -> IO ()' with actual type `()' * The function `()' is applied to one argument, but its type `()' has none In the expression: () main :: IO () In an equation for `a': a = () main :: IO () | 3 | a = ({-# LANGUAGE KindSignatures #-}) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, modules loaded: none. }}} Anyway the code you wrote is not pretty. Clarity of a program is very important especially in software maintenance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 11:14:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 11:14:49 -0000 Subject: [GHC] #13919: Incorrect unused top binding warning when interacting with GHC.Generics Message-ID: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> #13919: Incorrect unused top binding warning when interacting with GHC.Generics -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- The program {{{#!hs {-# LANGUAGE DeriveGeneric #-} module Main (main) where import Data.Aeson import GHC.Generics data Foo = Foo {bar :: String} deriving Generic instance ToJSON Foo where toJSON = genericToJSON defaultOptions main :: IO () main = print (toJSON (Foo "hello")) }}} emits the warning {{{ UTB.hs:7:17: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ }}} but removing that binding changes the behaviour of the program, as the above prints {{{ Object (fromList [("bar",String "hello")]) }}} but {{{#!hs {-# LANGUAGE DeriveGeneric #-} module Main (main) where import Data.Aeson import GHC.Generics data Foo = Foo String deriving Generic instance ToJSON Foo where toJSON = genericToJSON defaultOptions main :: IO () main = print (toJSON (Foo "hello")) }}} prints {{{ String "hello" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 11:31:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 11:31:31 -0000 Subject: =?utf-8?b?W0dIQ10gIzEzOTIwOiDoh6rli5Xpgbjmk4flr6bkvos=?= Message-ID: <044.aa257f029c0cff56b58137cded197a05@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- https://github.com/zaoqi/U.hs/blob/master/Data/U.hs:{{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction #-} module Data.U ( U(), t, u ) where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class T1 a b where t1 :: (U a) -> (U b) instance T1 a a where t1 = id instance T1 xs (x : xs) where t1 = USucc instance T1 (x : y : xs) (y : x : xs) where t1 (UOne x) = USucc (UOne x) t1 (USucc (UOne x)) = UOne x t1 (USucc (USucc xs)) = USucc (USucc xs) instance T1 xs ys => T1 (x : xs) (x : ys) where t1 (UOne x) = UOne x t1 (USucc xs) = USucc (t1 xs) t = t1 . t1 . t1 . t1 . t1 . t1 . t1 . t1 uone :: a -> U '[a] uone = UOne u x = t (uone x) instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs }}} {{{#!hs *Data.U> (u 'c') :: U [Int,Char] :12:2: error: • No instance for (T1 a30 '[Int, Char]) arising from a use of ‘u’ • In the expression: (u 'c') :: U '[Int, Char] In an equation for ‘it’: it = (u 'c') :: U '[Int, Char] *Data.U> t1 (uone 'c') :: U [Int,Char] (u 'c') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 11:34:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 11:34:36 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.a6b7e798f83fbe9dc3f3b57a056b5c2b@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by zaoqi): * version: 8.0.1 => 8.0.2 @@ -1,1 +1,2 @@ - https://github.com/zaoqi/U.hs/blob/master/Data/U.hs:{{{#!hs + https://github.com/zaoqi/U.hs/blob/master/Data/U.hs: + {{{#!hs New description: https://github.com/zaoqi/U.hs/blob/master/Data/U.hs: {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction #-} module Data.U ( U(), t, u ) where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class T1 a b where t1 :: (U a) -> (U b) instance T1 a a where t1 = id instance T1 xs (x : xs) where t1 = USucc instance T1 (x : y : xs) (y : x : xs) where t1 (UOne x) = USucc (UOne x) t1 (USucc (UOne x)) = UOne x t1 (USucc (USucc xs)) = USucc (USucc xs) instance T1 xs ys => T1 (x : xs) (x : ys) where t1 (UOne x) = UOne x t1 (USucc xs) = USucc (t1 xs) t = t1 . t1 . t1 . t1 . t1 . t1 . t1 . t1 uone :: a -> U '[a] uone = UOne u x = t (uone x) instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs }}} {{{#!hs *Data.U> (u 'c') :: U [Int,Char] :12:2: error: • No instance for (T1 a30 '[Int, Char]) arising from a use of ‘u’ • In the expression: (u 'c') :: U '[Int, Char] In an equation for ‘it’: it = (u 'c') :: U '[Int, Char] *Data.U> t1 (uone 'c') :: U [Int,Char] (u 'c') }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 14:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 14:49:36 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.c99519ee7068ac5e5785bc6db41c86b9@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by j.waldmann): > not pretty Please. It is not the compiler's task to check prettiness. There are extra tools for that, like https://hackage.haskell.org/package/hlint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 16:11:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 16:11:34 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.97ee9b3f8f093f1ccfcbb5f1264df097@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Here we go astray. We realize that by moving {{{main}}} of two spaces to the right there is a bug when the expression of {{{a}}} is put between brackets (e.g {{{(...)}}}).\\ On the other hand if {{{main}}} has its usual place and the brackets are not put around the expression of {{{a}}} there is a bug. And the designated line is not the right one in my opinion.\\ What does a member of the Committee think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 16:30:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 16:30:19 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.12551753293c0140e38602b7e0da5f48@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- @@ -57,1 +57,1 @@ - {{{#!hs + {{{ New description: https://github.com/zaoqi/U.hs/blob/master/Data/U.hs: {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction #-} module Data.U ( U(), t, u ) where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class T1 a b where t1 :: (U a) -> (U b) instance T1 a a where t1 = id instance T1 xs (x : xs) where t1 = USucc instance T1 (x : y : xs) (y : x : xs) where t1 (UOne x) = USucc (UOne x) t1 (USucc (UOne x)) = UOne x t1 (USucc (USucc xs)) = USucc (USucc xs) instance T1 xs ys => T1 (x : xs) (x : ys) where t1 (UOne x) = UOne x t1 (USucc xs) = USucc (t1 xs) t = t1 . t1 . t1 . t1 . t1 . t1 . t1 . t1 uone :: a -> U '[a] uone = UOne u x = t (uone x) instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs }}} {{{ *Data.U> (u 'c') :: U [Int,Char] :12:2: error: • No instance for (T1 a30 '[Int, Char]) arising from a use of ‘u’ • In the expression: (u 'c') :: U '[Int, Char] In an equation for ‘it’: it = (u 'c') :: U '[Int, Char] *Data.U> t1 (uone 'c') :: U [Int,Char] (u 'c') }}} -- Comment (by bgamari): I spent a few minutes looking at this: It seems like you want `(u 'c') :: U [Int,Char]` to behave like `t1 (uone 'c') :: U [Int,Char]`, but they are quite different. Can you provide some more description of the problem? What does GHC do and how does this differ from what you would want it to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 16:39:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 16:39:28 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.b3e381df4ec3833887bf206d843e19f2@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 | -------------------------------------+------------------------------------- Comment (by bgamari): > After thinking about this over. I think we'd be better split SIMD primitives into GHC.Prim.SSE4, GHC.Prim.AVX, etc. modules to avoid this compatibility hell. I'm afraid all of the primops will likely remain in `GHC.Prim` for tiresome engineering reasons (namely the `GHC.Prim` module is treated specially by the compiler; while we perhaps could add more wired-in modules, we'd rather not). However `GHC.Prim` isn't intended to be used by the user anyways. Perhaps we could reexport the SIMD primitives in a new `GHC.Exts.SIMD` module. Regardless, I don't think we want to bake architecture-specific details into GHC's module naming. Really, the SIMD support provided by GHC is, like all primops, intended to be a substrate over which library authors can write safer, more convenient abstractions. > BTW, is SSE4 suppose to be the baseline of x86_64 now? Builds on `x86_64` assume SSE2 and no more, AFAIK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:06:27 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas In-Reply-To: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> References: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> Message-ID: <059.ea5fb81584105cdeda53ebfe658a7b8a@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): > About LANGUAGE pragma, Can you quote the reference manual in which you read this sentence, please, and show me the page? It's never said terribly explicitly, that being said I think it's pretty reasonable to assume for syntactic consistency. That being said, I am a bit surprised that a LANGUAGE pragma is accepted here at all. Afterall, it's a file pragma and therefore should only occur before the `module` declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:08:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:08:26 -0000 Subject: [GHC] #13921: LANGUAGE pragma is accepted in module body Message-ID: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> #13921: LANGUAGE pragma is accepted in module body -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- As pointed out in #13918, the [[https://www.haskell.org/onlinereport/haskell2010/haskellch12.html#x19-19100012.3|Haskell Report]] stipulates that, > The LANGUAGE pragma is a file-header pragma. A file-header pragma must precede the module keyword in a source file. However, GHC accepts this program, {{{#!hs module Hi where h = {-# LANGUAGE BangPatterns #-} 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:08:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:08:59 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas In-Reply-To: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> References: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> Message-ID: <059.3bf807638cc3deb75ebcd10df04855aa@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #13921 to track the `LANGUAGE` pragma placement infelicity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:15:18 -0000 Subject: [GHC] #13921: LANGUAGE pragma is accepted in module body In-Reply-To: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> References: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> Message-ID: <061.ca46186705afb8a2ff25aab9a2b33c6c@haskell.org> #13921: LANGUAGE pragma is accepted in module body -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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 bgamari): I suppose it's arguably okay to treat the `LANGUAGE` pragma in this context as unknown and therefore ignore it. From the Report, > An implementation is not required to respect any pragma, although pragmas that are not recognised by the implementation should be ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:15:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:15:36 -0000 Subject: [GHC] #13921: LANGUAGE pragma is accepted in module body In-Reply-To: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> References: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> Message-ID: <061.b22ee10d56e1565e9e1e661e49337542@haskell.org> #13921: LANGUAGE pragma is accepted in module body -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 17:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 17:31:09 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.4d2797aae51691a05380b2ab4bc4547a@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Here's a more general approach that relies on plugins. {{{ addCorePlugin :: GhcPlugins.Plugin -> Q () }}} This arranges for a plugin to be inserted in the core2core passes. It saves the user the trouble of adding it at the top of the module: {{{ {-# OPTIONS_GHC -fplugin=... #-} }}} The plugin can find the result of quasiquotations by making a pass over the module looking for some special function inserted by the quasiquoter for that sake. I have observed that GHC does not link the GHC api into the final executable when using plugins, I would hope that it doesn't do it either if we add it this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 18:19:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 18:19:23 -0000 Subject: [GHC] #13919: Incorrect unused top binding warning when interacting with GHC.Generics In-Reply-To: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> References: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> Message-ID: <059.2abd7b746f710e2770aa3bc42e15c9ec@haskell.org> #13919: Incorrect unused top binding warning when interacting with GHC.Generics -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1954 | Differential Rev(s): Phab:D3704 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics * status: new => patch * differential: => Phab:D3704 * related: => #1954 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 18:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 18:35:45 -0000 Subject: [GHC] #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas In-Reply-To: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> References: <044.06a3c6aa0c55cfc70929844ee73c03f7@haskell.org> Message-ID: <059.948dd07c009c3433e963b9140d6f8efc@haskell.org> #13918: No "warning: [-Wunrecognised-pragmas] Unrecognised pragma" when there is no name of pragmas -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, bgamari )]]\\ From ticket #13921\\ >An implementation is not required to respect any pragma, although pragmas >that are not recognised by the implementation should be ignored.\\ Hello Ben,\\ Did you take a look at ticket {{{#13917}}}? He talks about the same thing from a different angle. Maybe this is interesting for the continuation of the ticket that you opened?(i.e ticket #13921) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 20:06:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 20:06:09 -0000 Subject: [GHC] #13921: LANGUAGE pragma is accepted in module body In-Reply-To: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> References: <046.f43a7724f76a883cce17ebd3c33598ca@haskell.org> Message-ID: <061.2f973e6513ea08be86185cd16366284c@haskell.org> #13921: LANGUAGE pragma is accepted in module body -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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 svenpanne): I would even go a step further: Syntactically, pragmas are just comments with a special content, so the example in the OP **must** be accepted from a language lawyer POV. It is equivalent (modulo column numbers) to: {{{#!haskell module Hi where h = 0 }}} From a developer POV, a warning would be nice, though. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 20:22:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 20:22:55 -0000 Subject: [GHC] #13922: Sort output of failed tests. Message-ID: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> #13922: Sort output of failed tests. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: 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 summary for failed tests can vary between runs. Sorting the output of {{{ "Unexpected results from: TEST="t1 t2..." }}} makes it easier to check for specific tests and to compare one run quickly with the result of another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 20:24:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 20:24:48 -0000 Subject: [GHC] #13922: Sort output of failed tests. In-Reply-To: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> References: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> Message-ID: <062.8a827b4ab241a637fe949185bfbd9e0e@haskell.org> #13922: Sort output of failed tests. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3705 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK * differential: => D3705 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 20:26:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 20:26:53 -0000 Subject: [GHC] #13922: Sort output of failed tests. In-Reply-To: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> References: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> Message-ID: <062.2ee31e90e1ada54a5eba94a8856553b0@haskell.org> #13922: Sort output of failed tests. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3705 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: D3705 => Phab:D3705 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 20:47:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 20:47:43 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.d4adb06a9ddecbaab8c933ba76cb9405@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): I should note that the same dilemma applies to `check-api-annotations`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 4 23:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Jul 2017 23:26:30 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.b38f3162e0b8da533b70a1d3c5197a38@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 | -------------------------------------+------------------------------------- Comment (by winter): I see, ghc-prim's current SIMD APIs seems support up to 512bits instructions. Does that means we are going to support up to AVX512? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 07:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 07:32:15 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.3ecfc0d144abe9a8c6cc7e5732e05682@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 zaoqi): Replying to [comment:2 bgamari]: > I spent a few minutes looking at this: It seems like you want `(u 'c') :: U [Int,Char]` to behave like `t1 (uone 'c') :: U [Int,Char]`, but they are quite different. > > Can you provide some more description of the problem? What does GHC do and how does this differ from what you would want it to do? {{{#!hs (t1 . t1 . t1 . t1 . t1 . t1 . t1) :: a -> a -- t1 = id t1 :: U '[Char] -> U [Int, Char] -- t1 = USucc t :: U '[Char] -> U [Int, Char] t (uone 'c') :: U [Int,Char] (u 'c') :: U [Int,Char] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 10:03:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 10:03:14 -0000 Subject: [GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl Message-ID: <049.278c5e90a08d18618906c14fe1c23641@haskell.org> #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 10:32:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 10:32:06 -0000 Subject: [GHC] #13924: join001 doesn't test anything related to join points Message-ID: <049.0d807008ea18a92f1bae0187e8fcf453@haskell.org> #13924: join001 doesn't test anything related to join points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- As far as I can see the same core is produced by 8.0.2 (before join points) and 8.2.1 (after join points). The test just tests whether the file `join001.hs` compiles without inspecting whether any join points are found and exploited. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:06:17 -0000 Subject: [GHC] #13925: Panic! Message-ID: <043.722cdd87978a17768d891d7f81e22424@haskell.org> #13925: Panic! -------------------------------------+------------------------------------- Reporter: Deus | 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: -------------------------------------+------------------------------------- Hi, I only use haskell for an asingement so I don't have any clues, but ghc told me to do a bug report: [1 of 1] Compiling Main ( plant.hs, plant.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] true_a1Gg :: t_a1Gf[tau:1] (CHoleCan: true) [W] false_a1Gj :: t_a1Gi[tau:1] (CHoleCan: false) [W] true_a1Qq :: t_a1Qp[tau:1] (CHoleCan: true)} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:06:41 -0000 Subject: [GHC] #13926: Panic! Message-ID: <043.8a8a52431625e6812b008123ea3d9163@haskell.org> #13926: Panic! -------------------------------------+------------------------------------- Reporter: Deus | 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: -------------------------------------+------------------------------------- Hi, I only use haskell for an asingement so I don't have any clues, but ghc told me to do a bug report: [1 of 1] Compiling Main ( plant.hs, plant.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] true_a1Gg :: t_a1Gf[tau:1] (CHoleCan: true) [W] false_a1Gj :: t_a1Gi[tau:1] (CHoleCan: false) [W] true_a1Qq :: t_a1Qp[tau:1] (CHoleCan: true)} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:10:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:10:48 -0000 Subject: [GHC] #13927: Panic! Message-ID: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Hi, I'm using haskell for an assignment and I createt this (which told me to do a bug report): [1 of 1] Compiling Main ( plant.hs, plant.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] true_a1Gg :: t_a1Gf[tau:1] (CHoleCan: true) [W] false_a1Gj :: t_a1Gi[tau:1] (CHoleCan: false) [W] true_a1Qq :: t_a1Qp[tau:1] (CHoleCan: true)} {{{#!hs data Farbe = Rot | Rosa | Weis | Blau | Lila | Grun | Gelb deriving (Show, Eq) data Pflanze = Blatt | Blute Farbe | Stiel Pflanze Pflanze deriving (Show, Eq) fold_pflanze :: (a -> a -> a) -> (Farbe -> a) -> a -> Pflanze -> a fold_pflanze f g x (Blatt) = x fold_pflanze f g x (Blute fa) = (f x (g fa)) fold_pflanze f g x (Stiel p1 p2) = fold_pflanze f g (fold_pflanze f g x p1) p2 --4. farbezuliste :: Farbe -> [Farbe] farbezuliste f = [f] appendlisten :: [Farbe] -> [Farbe] -> [Farbe] appendlisten f1 f2 = f1 ++ f2 blutenfarben :: Pflanze -> [Farbe] blutenfarben p = fold_pflanze appendlisten farbezuliste [] p --5. fold_pflanze2 :: (Farbe -> Int) -> Int -> Pflanze -> Int fold_pflanze2 f x (Blatt) = x + 1; fold_pflanze2 f x (Blute fa) = x + (f fa) fold_pflanze2 f x (Stiel p1 p2) = (-2) + (fold_pflanze2 f (fold_pflanze2 f x p1) p2) evaluatefarbe :: Farbe -> Int evaluatefarbe Rot = 2 evaluatefarbe Rosa = 3 evaluatefarbe Weis = 5 evaluatefarbe Blau = 1 evaluatefarbe Lila = 10 evaluatefarbe Grun = -1 evaluatefarbe Gelb = 0 schonheit :: Pflanze -> Int schonheit p = fold_pflanze2 evaluatefarbe 0 p --6. istrosa :: Farbe -> Bool istrosa Rosa = true istrosa otherwise = false und :: Bool -> Bool -> Bool und x y = x && y rosabluhend :: Pflanze -> Bool rosabluhend p = fold_pflanze und istrosa true p }}} I tryed to add the code as attechment bug it crashed (It also told me to do a bug report but I have an assignment to do). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:14:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:14:00 -0000 Subject: [GHC] #13927: Panic! In-Reply-To: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> References: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> Message-ID: <058.db639e551f08b6cfe3f5a125b5d366c6@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by Deus: @@ -73,0 +73,3 @@ + + EDIT: + It seems to be the part that belongs to 6 New description: Hi, I'm using haskell for an assignment and I createt this (which told me to do a bug report): [1 of 1] Compiling Main ( plant.hs, plant.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] true_a1Gg :: t_a1Gf[tau:1] (CHoleCan: true) [W] false_a1Gj :: t_a1Gi[tau:1] (CHoleCan: false) [W] true_a1Qq :: t_a1Qp[tau:1] (CHoleCan: true)} {{{#!hs data Farbe = Rot | Rosa | Weis | Blau | Lila | Grun | Gelb deriving (Show, Eq) data Pflanze = Blatt | Blute Farbe | Stiel Pflanze Pflanze deriving (Show, Eq) fold_pflanze :: (a -> a -> a) -> (Farbe -> a) -> a -> Pflanze -> a fold_pflanze f g x (Blatt) = x fold_pflanze f g x (Blute fa) = (f x (g fa)) fold_pflanze f g x (Stiel p1 p2) = fold_pflanze f g (fold_pflanze f g x p1) p2 --4. farbezuliste :: Farbe -> [Farbe] farbezuliste f = [f] appendlisten :: [Farbe] -> [Farbe] -> [Farbe] appendlisten f1 f2 = f1 ++ f2 blutenfarben :: Pflanze -> [Farbe] blutenfarben p = fold_pflanze appendlisten farbezuliste [] p --5. fold_pflanze2 :: (Farbe -> Int) -> Int -> Pflanze -> Int fold_pflanze2 f x (Blatt) = x + 1; fold_pflanze2 f x (Blute fa) = x + (f fa) fold_pflanze2 f x (Stiel p1 p2) = (-2) + (fold_pflanze2 f (fold_pflanze2 f x p1) p2) evaluatefarbe :: Farbe -> Int evaluatefarbe Rot = 2 evaluatefarbe Rosa = 3 evaluatefarbe Weis = 5 evaluatefarbe Blau = 1 evaluatefarbe Lila = 10 evaluatefarbe Grun = -1 evaluatefarbe Gelb = 0 schonheit :: Pflanze -> Int schonheit p = fold_pflanze2 evaluatefarbe 0 p --6. istrosa :: Farbe -> Bool istrosa Rosa = true istrosa otherwise = false und :: Bool -> Bool -> Bool und x y = x && y rosabluhend :: Pflanze -> Bool rosabluhend p = fold_pflanze und istrosa true p }}} I tryed to add the code as attechment bug it crashed (It also told me to do a bug report but I have an assignment to do). EDIT: It seems to be the part that belongs to 6 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:20:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:20:53 -0000 Subject: [GHC] #13925: Panic! In-Reply-To: <043.722cdd87978a17768d891d7f81e22424@haskell.org> References: <043.722cdd87978a17768d891d7f81e22424@haskell.org> Message-ID: <058.c9dfed4fe14efa600a51ec1904998f0c@haskell.org> #13925: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Looks like this has been subsumed by #13927. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:21:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:21:22 -0000 Subject: [GHC] #13926: Panic! In-Reply-To: <043.8a8a52431625e6812b008123ea3d9163@haskell.org> References: <043.8a8a52431625e6812b008123ea3d9163@haskell.org> Message-ID: <058.bb410090c5090b9e7133d4c4863a22ac@haskell.org> #13926: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Looks like this has been subsumed by #13927. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:28:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:28:58 -0000 Subject: [GHC] #13927: Panic! In-Reply-To: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> References: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> Message-ID: <058.789ff35bef80fb449fdc5dea85e45824@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks very much for reporting! I believe this bug has been fixed (see #12921), but I also cannot reproduce it. Are there `import` statements or the `module` header at the top of your file? We'd need to be able to reproduce the error in order to verify that it's fixed. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 12:52:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 12:52:43 -0000 Subject: [GHC] #13927: Panic! In-Reply-To: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> References: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> Message-ID: <058.4246d0e98127d401c919fbcc23250814@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Deus): Thats the hole code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 13:44:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 13:44:48 -0000 Subject: [GHC] #13928: Providing a more specific argument prevents fusion caused by join point floating. Message-ID: <049.61d7de27073b0ca7786b631f684c0bdc@haskell.org> #13928: Providing a more specific argument prevents fusion caused by join point floating. -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- I don't know whether this is expected or not but I am writing it down here for the record. Defining `any` as in section 5 of the paper "compiling without continuations" produces nice fused code as promised. However, fixing the predicate in `any` causes the fusion to stop happening producing potentially worse code. {{{ module ListFusion where find :: (a -> Bool) -> [a] -> Maybe a find p xs = go xs where go [] = Nothing go (x:xs) = if p x then Just x else go xs fuses :: (Int -> Bool) -> [Int] -> Bool fuses p xs = case find p xs of Just x -> True Nothing -> False fuseNot :: (Int -> Bool) -> [Int] -> Bool fuseNot _p xs = case find (> 4) xs of Just x -> True Nothing -> False }}} Core output {{{ [1 of 1] Compiling ListFusion ( listfusion.hs, listfusion.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 87, types: 82, coercions: 0, joins: 2/2} -- RHS size: {terms: 21, types: 20, coercions: 0, joins: 1/1} find :: forall a. (a -> Bool) -> [a] -> Maybe a [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_a1UH) (p_aSB [Occ=OnceL!] :: a_a1UH -> Bool) (xs_aSC [Occ=Once] :: [a_a1UH]) -> joinrec { go_s28Z [Occ=LoopBreakerT[1]] :: [a_a1UH] -> Maybe a_a1UH [LclId[JoinId(1)], Arity=1, Unf=OtherCon []] go_s28Z (ds_d27L [Occ=Once!] :: [a_a1UH]) = case ds_d27L of { [] -> GHC.Base.Nothing @ a_a1UH; : x_aSE xs1_aSF [Occ=Once] -> case p_aSB x_aSE of { False -> jump go_s28Z xs1_aSF; True -> GHC.Base.Just @ a_a1UH x_aSE } }; } in jump go_s28Z xs_aSC}] find = \ (@ a_a1UH) (p_aSB :: a_a1UH -> Bool) (xs_aSC :: [a_a1UH]) -> joinrec { go_s28Z [Occ=LoopBreaker] :: [a_a1UH] -> Maybe a_a1UH [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] go_s28Z (ds_d27L :: [a_a1UH]) = case ds_d27L of { [] -> GHC.Base.Nothing @ a_a1UH; : x_aSE xs1_aSF -> case p_aSB x_aSE of { False -> jump go_s28Z xs1_aSF; True -> GHC.Base.Just @ a_a1UH x_aSE } }; } in jump go_s28Z xs_aSC -- RHS size: {terms: 19, types: 15, coercions: 0, joins: 1/1} fuses :: (Int -> Bool) -> [Int] -> Bool [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (p_aSG [Occ=OnceL!] :: Int -> Bool) (xs_aSH [Occ=Once] :: [Int]) -> joinrec { go_s28X [Occ=LoopBreakerT[1]] :: [Int] -> Bool [LclId[JoinId(1)], Arity=1, Unf=OtherCon []] go_s28X (ds_d27L [Occ=Once!] :: [Int]) = case ds_d27L of { [] -> GHC.Types.False; : x_aSE [Occ=Once] xs1_aSF [Occ=Once] -> case p_aSG x_aSE of { False -> jump go_s28X xs1_aSF; True -> GHC.Types.True } }; } in jump go_s28X xs_aSH}] fuses = \ (p_aSG :: Int -> Bool) (xs_aSH :: [Int]) -> joinrec { go_s28X [Occ=LoopBreaker] :: [Int] -> Bool [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] go_s28X (ds_d27L :: [Int]) = case ds_d27L of { [] -> GHC.Types.False; : x_aSE xs1_aSF -> case p_aSG x_aSE of { False -> jump go_s28X xs1_aSF; True -> GHC.Types.True } }; } in jump go_s28X xs_aSH -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} ListFusion.$trModule4 :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ListFusion.$trModule4 = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} ListFusion.$trModule3 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] ListFusion.$trModule3 = GHC.Types.TrNameS ListFusion.$trModule4 -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} ListFusion.$trModule2 :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 40 0}] ListFusion.$trModule2 = "ListFusion"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} ListFusion.$trModule1 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] ListFusion.$trModule1 = GHC.Types.TrNameS ListFusion.$trModule2 -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} ListFusion.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] ListFusion.$trModule = GHC.Types.Module ListFusion.$trModule3 ListFusion.$trModule1 Rec { -- RHS size: {terms: 20, types: 13, coercions: 0, joins: 0/0} ListFusion.fuseNot_go [Occ=LoopBreaker] :: [Int] -> Maybe Int [GblId, Arity=1, Caf=NoCafRefs, Str=] ListFusion.fuseNot_go = \ (ds_d27L :: [Int]) -> case ds_d27L of { [] -> GHC.Base.Nothing @ Int; : x_aSE xs_aSF -> case x_aSE of wild1_a28o { GHC.Types.I# x1_a28q -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.># x1_a28q 4#) of { False -> ListFusion.fuseNot_go xs_aSF; True -> GHC.Base.Just @ Int wild1_a28o } } } end Rec } -- RHS size: {terms: 9, types: 7, coercions: 0, joins: 0/0} fuseNot :: (Int -> Bool) -> [Int] -> Bool [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] (xs_aSK [Occ=Once] :: [Int]) -> case ListFusion.fuseNot_go xs_aSK of { Nothing -> GHC.Types.False; Just _ [Occ=Dead] -> GHC.Types.True }}] fuseNot = \ _ [Occ=Dead] (xs_aSK :: [Int]) -> case ListFusion.fuseNot_go xs_aSK of { Nothing -> GHC.Types.False; Just x_a1U5 -> GHC.Types.True } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 15:15:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 15:15:02 -0000 Subject: [GHC] #13927: Panic! In-Reply-To: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> References: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> Message-ID: <058.9012261d85fc9cc151bf705afc9e6b86@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is a duplicate of #13106. It panics in 8.0.2 (you need to compile with `ghc`, not `ghci`) but not in GHC 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | data Farbe = Rot | Rosa | Weis | Blau | Lila | Grun | Gelb | ^ Bug.hs:46:16: error: • Variable not in scope: true :: Bool • Perhaps you meant data constructor ‘True’ (imported from Prelude) | 46 | istrosa Rosa = true | ^^^^ Bug.hs:47:21: error: • Variable not in scope: false :: Bool • Perhaps you meant data constructor ‘False’ (imported from Prelude) | 47 | istrosa otherwise = false | ^^^^^ Bug.hs:53:42: error: • Variable not in scope: true :: Bool • Perhaps you meant data constructor ‘True’ (imported from Prelude) | 53 | rosabluhend p = fold_pflanze und istrosa true p | ^^^^ }}} Alternatively, you can make the panic go away by just adding `module Plant where` at the top of the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 15:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 15:17:41 -0000 Subject: [GHC] #13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec In-Reply-To: <048.687561c0b2094c184d470f52797d1735@haskell.org> References: <048.687561c0b2094c184d470f52797d1735@haskell.org> Message-ID: <063.ee4bdb25acdd8003366aa8fa7b5cb9e3@haskell.org> #13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec -------------------------------------+------------------------------------- Reporter: timmyjose | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: parsec, | ghc8.0.2, macOS Sierra Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. In 8.2.1, I get a reasonable error message: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | import Text.ParserCombinators.Parsec hiding (spaces) | ^ Bug.hs:4:10: error: Variable not in scope: anyOf :: [Char] -> Parser Char | 4 | symbol = anyOf "!$%&|*+-/:<=?>@^_^~#" | ^^^^^ }}} Alternatively, you can make the panic go away in 8.0.2 by just adding `module SimpleParser where` at the top of the file (the lack of `main` is confusing GHC in 8.0.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 15:18:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 15:18:01 -0000 Subject: [GHC] #13927: Panic! In-Reply-To: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> References: <043.d45388d00c09ddeed8664c5ce6c58ead@haskell.org> Message-ID: <058.b7983ce28280714365a78ac1bd7c74c0@haskell.org> #13927: Panic! -------------------------------------+------------------------------------- Reporter: Deus | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 16:51:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 16:51:55 -0000 Subject: [GHC] #13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec In-Reply-To: <048.687561c0b2094c184d470f52797d1735@haskell.org> References: <048.687561c0b2094c184d470f52797d1735@haskell.org> Message-ID: <063.ae721be14ae3eba64d97069c24764634@haskell.org> #13889: GHC 8.0.2 panics when trying a simple snippet involving Parsec -------------------------------------+------------------------------------- Reporter: timmyjose | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: parsec, | ghc8.0.2, macOS Sierra Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by timmyjose): Thank you! I think it's high time I upgraded my GHC version in any case, so thanks for confirming that the bug had already long been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 17:57:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 17:57:58 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.1d2adf04a399d8b3c59f3a596ee1cbef@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lexi.lambda): * cc: lexi.lambda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 18:42:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 18:42:17 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.4fb9526f933c1d6e1b917b46ea8f0e7b@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) 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 | -------------------------------------+------------------------------------- Comment (by bgamari): It depends upon who steps up to implement this plan :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 18:44:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 18:44:21 -0000 Subject: [GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl In-Reply-To: <049.278c5e90a08d18618906c14fe1c23641@haskell.org> References: <049.278c5e90a08d18618906c14fe1c23641@haskell.org> Message-ID: <064.30778270f6c1ba4b47ae4deafc756a93@haskell.org> #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): You could probably filter them out by name pretty easily. Just add a special case to the `HsBind` and `Bind` `Outputable` instances with an associated `DynFlag`. I'm not sure whether you really want to stop emitting them entirely; afterall, then some programs would fail to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 5 21:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Jul 2017 21:02:42 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism Message-ID: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> #13929: GHC panic with levity polymorphism --------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I'm using GHC version 8.2.0.20170507 This code fails to compile {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Main where import GHC.Exts import Data.Kind import GHC.Generics class GUnbox (f :: Type -> Type) (r :: RuntimeRep) where type GUnboxed f r :: TYPE r gunbox :: f p -> GUnboxed f r instance (GUnbox f rf, GUnbox g rg) => GUnbox (f :*: g) ('TupleRep '[rf, rg]) where type GUnboxed (f :*: g) ('TupleRep '[rf, rg]) = (# GUnboxed f rf, GUnboxed g rg #) -- if I remove implementation of `gunbox` it compiles successfully gunbox (x :*: y) = (# gunbox x, gunbox y #) main :: IO () main = pure () }}} with message: {{{ [1 of 1] Compiling Main ( Main.hs, .stack- work\dist\f42fcbca\build\Main.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-mingw32): isUnliftedType GUnboxed g_a21y rg_a21z :: TYPE rg_a21z Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler\types\Type.hs:1954:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 02:31:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 02:31:02 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.99a1bd55e31dd970653c61f729485627@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by dfeuer): If I remove the size calculation altogether, allowing unlimited simplifier ticks, then we get performance regressions. This suggests that some of the leaks are still with us, although apparently not nearly as severe as they once were. I'm working on making the size calculation a bit more efficient, but we're going to leave the rest alone for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 03:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 03:36:31 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.9b128759f1e15e6af2a3e8ff6f741429@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "Vector.hs" added. A slightly smaller example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:04:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:04:19 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "Vector.hs" removed. A slightly smaller example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:04:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:04:20 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.5927bc83a521ae65fe3624713cfd14dd@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "Vector.hs" added. Reduced a little more -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:18:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:18:44 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.1e1dff440fff9f6c4db204b3b5df6daf@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Starting with `vector` 1d208ee9e3a252941ebd112e14e8cd5a982ac2bb, replace `tests/Test/Vector.hs` with the attached file. Compile using {{{ -no-link -fbuilding-cabal-package -static -dynamic-too -dynosuf dyn_o \ -dynhisuf dyn_hi -outputdir dist/build/vector-tests-O2/vector-tests-O2-tmp \ -odir dist/build/vector-tests-O2/vector-tests-O2-tmp -hidir \ dist/build/vector-tests-O2/vector-tests-O2-tmp -stubdir \ dist/build/vector-tests-O2/vector-tests-O2-tmp -i \ -idist/build/vector-tests-O2/vector-tests-O2-tmp -itests \ -idist/build/autogen -Idist/build/autogen \ -Idist/build/vector-tests-O2/vector-tests-O2-tmp \ -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages \ -package-db dist/package.conf.inplace -package HUnit-1.6.0.0 \ -package QuickCheck-2.9.2 -package base -package random-1.1 -package \ template-haskell -package test-framework-0.8.1.1 -package \ test-framework-hunit-0.3.0.2 -package test-framework-quickcheck2-0.3.0.3 \ -package transformers-0.5.2.0 -package vector-0.12.0.1 -XHaskell2010 \ -XCPP -XScopedTypeVariables -XPatternGuards -XMultiParamTypeClasses \ -XFlexibleContexts -XRank2Types -XTypeSynonymInstances -XTypeFamilies \ -XTemplateHaskell tests/Tests/Vector.hs -O2 -fno-warn-orphans \ -fno-warn-missing-signatures -Rghc-timing -v -ddump-simpl -ddump-to-file }}} In the below, the "offending patch" is 1c4a39d3a8d36803382792ff78b4709794358883 and "recent HEAD" is 7097f94df0c6667be2343306ffcda152fa22abcf. Allocations: 1. Before the offending patch: 13,445,819,064 2. After the offending patch: 135,653,550,528 (10x worse) 3. Recent HEAD: 71,354,312,480 (~5x worse) Tidy core size (terms) 1. Before offending: 20,934 2. After offending: 170,128 3. Recent HEAD: 170,023 Maximum reported core size (terms) before Tidy Core: 1. Before offending: 45,213 2. After offending: 1,358,264 3. Recent HEAD: 503,803 So we are clearly generating ''far'' more code, and while we eliminate a lot of it, we're still left with an awful lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:37:05 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.f16b5f3895fa4f201dd44270143c1fa9@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "ds-diff" added. dump-ds diff for offending patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:38:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:38:08 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.f6e51390abdd15a08524a39ab10c7584@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've attached a diff of the results of `-ddump-ds -dsuppress-uniques` before and after the offending patch. The change looks pretty small, but something is blowing everything up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 04:40:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 04:40:31 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.2d49f418a8e2f42456457a1b98f57d0d@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "ds.diff" added. Proper extension on the diff -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 12:47:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 12:47:08 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.94b3a3e92ebe4bcf988879fe4d1b6a99@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 12:47:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 12:47:48 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.170a7dd0cfe2782c2c343845d516e12c@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 13:05:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 13:05:29 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.5ec589e598d1c758393b7a687a87565c@haskell.org> #13929: GHC panic with levity polymorphism ---------------------------------+-------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * cc: goldfire (added) Comment: Thanks for the bug report and nice reproducer! Adding goldfire to CC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 13:23:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 13:23:32 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.72dafb0bd3918e4798043a3fecfccf24@haskell.org> #13929: GHC panic with levity polymorphism ---------------------------------+-------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) Comment: Fun example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 13:24:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 13:24:05 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.c361730a5130ee1bb30806f12003fc30@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 17:03:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 17:03:58 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.0978313ffde5140cc61497a63172a695@haskell.org> #13929: GHC panic with levity polymorphism ---------------------------------+-------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 18:04:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 18:04:58 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.a8f09b9f9a37d85cf27448cb30d6e977@haskell.org> #13929: GHC panic with levity polymorphism ---------------------------------+-------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): For the record, a more complete callstack is, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): isUnliftedType GUnboxed g_a20x rg_a20y :: TYPE rg_a20y Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1954:10 in ghc:Type isUnliftedType, called at compiler/coreSyn/CoreUtils.hs:487:27 in ghc:CoreUtils needsCaseBinding, called at compiler/coreSyn/MkCore.hs:162:10 in ghc:MkCore mk_val_app, called at compiler/coreSyn/MkCore.hs:146:42 in ghc:MkCore mkCoreApps, called at compiler/coreSyn/MkCore.hs:154:26 in ghc:MkCore mkCoreConApps, called at compiler/coreSyn/MkCore.hs:364:5 in ghc:MkCore mkCoreUbxTup, called at compiler/coreSyn/MkCore.hs:370:32 in ghc:MkCore mkCoreTupBoxity, called at compiler/deSugar/DsExpr.hs:382:19 in ghc:DsExpr Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 18:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 18:47:32 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.407eb15014a2f8732ac3682e655fac9b@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: TypeInType => TypeInType, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 18:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 18:47:51 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.e4aeea5879c17f6dcf278e1b8c01a4b1@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 18:51:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 18:51:31 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.c9a1751a2817e64f1f614cd8cd592267@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism 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 bgamari): To be clear, I don't think (although could be wrong) this program should compile; afterall, the type of `gunbox` requires that we represent a levity polymorphic result, which we cannot do. Hence, the real bug here is the panic instead of a proper type error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 19:03:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 19:03:50 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.6d2b060fcb204dca2d4048712cdb2f6d@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism 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 vagarenko): Replying to [comment:7 bgamari]: > To be clear, I don't think (although could be wrong) this program should compile; afterall, the type of `gunbox` requires that we represent a levity polymorphic result, which we cannot do. Hence, the real bug here is the panic instead of a proper type error. I think levity polymorphism paper says you can't have functions with levity-polymorphic parameters, levity-polymorphic results are OK. This compiles fine: {{{#!hs instance (GUnbox f r) => GUnbox (M1 i t f) r where type GUnboxed (M1 i t f) r = GUnboxed f r gunbox (M1 x) = gunbox x }}} But unboxed sum also fails to compile: {{{#!hs instance (GUnbox f rf, GUnbox g rg) => GUnbox (f :+: g) ('SumRep '[rf, rg]) where type GUnboxed (f :+: g) ('SumRep '[rf, rg]) = (# GUnboxed f rf | GUnboxed g rg #) gunbox (L1 l) = (# gunbox l | #) gunbox (R1 r) = (# | gunbox r #) }}} with the same message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 20:09:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 20:09:04 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.51d9ebb82daf20154356a99f8442634e@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I see that GHC HEAD now optimizes the gigantic redundant `case` away (eventually), but it still goes more slowly than we'd like. For example, in GHC 7.10, `-ddump-spec` shows that all the redundant crud is already gone, whereas on GHC 8.3, it is still there then. I would like to understand how 7.10 gets rid of the extra cases before demand analysis. Is it using the fact that there are nested matches on the same constructor? Does that test not ignore type arguments it should? Interestingly, it seems that at a certain point `bool` actually gets inlined at a bunch of call sites (some in normal terms; some in unfoldings), but not all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 23:42:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 23:42:57 -0000 Subject: [GHC] #13930: Cabal configure Message-ID: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> #13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- `cabal configure` apparently has a space leak when compiled with GHC HEAD but not 8.0. It's not clear whether this is really a GHC regression yet, but here it is certainly GHC version-specific. See https://github.com/haskell/cabal/issues/4589 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 6 23:43:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Jul 2017 23:43:15 -0000 Subject: [GHC] #13930: Cabal configure In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.03c79a6d340694413fd54052afd0e9f5@haskell.org> #13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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 bgamari): Thankfully it seems like 8.2 isn't affected by this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:11:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:11:46 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? Message-ID: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I asked this on stackoverflow first https://stackoverflow.com/questions/44958114/why-these-type-family- instances-conflicting I'm using GHC-8.0.1. This code (requires singletons lib): {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Singletons type family MkCtx (kx :: Type) (kc :: Type) (c :: kc) (x :: kx) :: Constraint type instance MkCtx kx (kx ~> Constraint) c x = Apply c x type instance MkCtx kx (kx -> Constraint) c x = c x }}} with the message: {{{ Conflicting family instance declarations: forall kx (x :: kx) (c :: kx ~> Constraint). MkCtx kx (kx ~> Constraint) c x = Apply c x forall kx (x :: kx) (c :: kx -> Constraint). MkCtx kx (kx -> Constraint) c x = c x }}} Why GHC considers these instances conflicting? I don't see how they overlap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:50:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:50:18 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? In-Reply-To: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> References: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> Message-ID: <063.333b84c6d316f4d87aa596d5b7a185f8@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This is, by a very circuitous route, a duplicate of #11715. Examine the definition of `~>`: {{{#!hs data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type }}} We can rewrite your first instance as {{{#!hs type instance MkCtx kx (TyFun kx Constraint -> Type) c x = Apply c x }}} Due to #11715, GHC can't differentiate between `Constraint` and `Type` in Core. This means that it would be unsafe to differentiate between these in a type family in Haskell (because type family instances in Haskell become type equality axioms in Core). So, let's replace `Type` and `Constraint` with `TC`. Then, our instances look like (with also some renaming) {{{#!hs type instance MkCtx kx1 (TyFun kx1 TC -> TC) c1 x1 = Apply c1 x1 type instance MkCtx kx2 (kx2 -> TC) c2 x2 = c2 x2 }}} Now, we must recall that the type family instance check uses ''infinitary'' unification (as documented [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #compatibility-and-apartness-of-type-family-equations here] and explained in Section 6.3 of [http://cs.brynmawr.edu/~rae/papers/2014/axioms/axioms.pdf this paper]). Thus, the left-hand sides unify under the substitution `kx1 |-> TyFun kx1 TC`. And so GHC rejects these instances. This is a terribly sad story, but it's not a fresh bug, I'm afraid. Both of the problems that lead to this problem, #11715 and the need for infinitary unification, are active [https://github.com/ghc-proposals/ghc- proposals/pull/32 areas] of [http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf work]. If you agree with my analysis, please close this ticket, as I don't think keeping it open adds fresh insight to either problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:54:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:54:13 -0000 Subject: [GHC] #13930: Cabal configure In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.ec6b5fdc14860990c119eb44b95cf911@haskell.org> #13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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 bgamari): Unfortunately I can't easily bisect this due to `Cabal` issue [https://github.com/haskell/cabal/issues/4509|#4509] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:55:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:55:01 -0000 Subject: [GHC] #13932: GHCi dumps "panic!" ("initTc: unsolved constraints") Message-ID: <046.44594cf92538b428c741afbeb490daf5@haskell.org> #13932: GHCi dumps "panic!" ("initTc: unsolved constraints") --------------------------------------+------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: ghci | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- Hi, I'm Japanese. I'm developping https://github.com/aiya000/hs-zuramaru now :) A problem is happend in https://github.com/aiya000/hs- zuramaru/commit/79b850167537afe9efa4f812ef6ce02ec129630c ! ghci says {{{ [7 of 9] Compiling Maru.Main ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Main.hs, inte ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] makeLensesWith_amym :: t_amyl[tau:1] (CHoleCan: makeLensesWith) [W] .~_amyv :: t_amyu[tau:1] (CHoleCan: .~) [W] &_amyE :: t_amyD[tau:1] (CHoleCan: &) [W] lensRules_amyL :: t_amyK[tau:1] (CHoleCan: lensRules)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (This is shorten message, I'll write full message to last line) It maybe happened after I introduced extensible-effects and microlens (microlens-th, microlens-mtl), and used it. I cannot understand details of the problem x( My linux distribution is {{{ $ uname -a Linux BlueAloha 4.6.0-1-surfacepro3 #1 SMP PREEMPT Wed Apr 5 14:12:33 JST 2017 x86_64 GNU/Linux }}} Below line is the full message of ghci {{{ No extra-dep setting found for package at URL: https://github.com/aiya000/hs-throwable-exceptions.git This is usually a mistake, external packages should typically be treated as extra-deps to avoid spurious test case failures. No extra-dep setting found for package at URL: https://github.com/aiya000/hs-throwable-exceptions.git This is usually a mistake, external packages should typically be treated as extra-deps to avoid spurious test case failures. No extra-dep setting found for package at URL: https://github.com/aiya000/hs-throwable-exceptions.git This is usually a mistake, external packages should typically be treated as extra-deps to avoid spurious test case failures. No extra-dep setting found for package at URL: https://github.com/aiya000/hs-throwable-exceptions.git This is usually a mistake, external packages should typically be treated as extra-deps to avoid spurious test case failures. zuramaru-0.1.0.0: initial-build-steps (lib + exe) Log files have been written to: /home/aiya000/Repository/hs-zuramaru /.stack-work/logs/ The following GHC options are incompatible with GHCi and have not been passed to it: -threaded Configuring GHCi with the following packages: zuramaru, throwable- exceptions Using main module: 1. Package `zuramaru' component exe:maru with main-is file: /home/aiya000/Repository/hs-zuramaru/app/Main.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/aiya000/.dotfiles/.ghci [1 of 7] Compiling Maru.Type.SExpr ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Type/SExpr.hs, interpreted ) [2 of 7] Compiling Maru.Type.Parser ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Type/Parser.hs, interpreted ) /home/aiya000/Repository/hs-zuramaru/src/Maru/Type/Parser.hs:46:1-22: Splicing declarations makeLenses ''MaruState ======> parseLogs :: Lens.Micro.Type.Lens' MaruState [ParseLog] parseLogs f_ahmF (MaruState x_ahmG x_ahmH) = fmap (\ y_ahmI -> MaruState y_ahmI x_ahmH) (f_ahmF x_ahmG) {-# INLINE parseLogs #-} parseNestLevel :: Lens.Micro.Type.Lens' MaruState Int parseNestLevel f_ahmJ (MaruState x_ahmK x_ahmL) = fmap (\ y_ahmM -> MaruState x_ahmK y_ahmM) (f_ahmJ x_ahmL) {-# INLINE parseNestLevel #-} [3 of 7] Compiling Maru.Type ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Type.hs, interpreted ) [4 of 7] Compiling Maru.Parser ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Parser.hs, interpreted ) [5 of 7] Compiling Control.Exception.Throwable.TH ( /home/aiya000/Repository/hs-zuramaru/.stack- work/downloaded/iT3mDZWO7QnR/src/Control/Exception/Throwable/TH.hs, interpreted ) [6 of 7] Compiling Maru.Eval ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Eval.hs, interpreted ) /home/aiya000/Repository/hs-zuramaru/src/Maru/Eval.hs:29:1-66: Splicing declarations declareException "NoSuchSymbolException" ["NoSuchSymbolException"] ======> data NoSuchSymbolException a_akj2 = NoSuchSymbolException {noSuchSymbolExceptionCause :: String, noSuchSymbolExceptionClue :: a_akj2} instance Show a_akj3 => Show (NoSuchSymbolException a_akj3) where show (NoSuchSymbolException cause_akj4 _) = ("NoSuchSymbolException: " ++ (show cause_akj4)) instance (Typeable a_akj5, Show a_akj5) => Exception (NoSuchSymbolException a_akj5) noSuchSymbolException :: String -> NoSuchSymbolException () noSuchSymbolException x_akj6 = NoSuchSymbolException x_akj6 () /home/aiya000/Repository/hs-zuramaru/src/Maru/Eval.hs:41:1: warning: [-Worphans] Orphan instance: instance (Monoid a, Monad m) => MonadFail (EitherT a m) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. /home/aiya000/Repository/hs-zuramaru/src/Maru/Eval.hs:106:24: warning: [-Wunused-matches] Defined but not used: ‘x’ /home/aiya000/Repository/hs-zuramaru/src/Maru/Eval.hs:109:13: warning: [-Wunused-local-binds] Defined but not used: ‘val’ [7 of 7] Compiling Maru.Main ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] makeLensesWith_amlb :: t_amla[tau:1] (CHoleCan: makeLensesWith) [W] .~_amlk :: t_amlj[tau:1] (CHoleCan: .~) [W] &_amlt :: t_amls[tau:1] (CHoleCan: &) [W] lensRules_amlA :: t_amlz[tau:1] (CHoleCan: lensRules)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [7 of 8] Compiling Maru.Main ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Main.hs, inte ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] makeLensesWith_amsk :: t_amsj[tau:1] (CHoleCan: makeLensesWith) [W] .~_amst :: t_amss[tau:1] (CHoleCan: .~) [W] &_amsC :: t_amsB[tau:1] (CHoleCan: &) [W] lensRules_amsJ :: t_amsI[tau:1] (CHoleCan: lensRules)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [7 of 9] Compiling Maru.Main ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Main.hs, inte ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] makeLensesWith_amym :: t_amyl[tau:1] (CHoleCan: makeLensesWith) [W] .~_amyv :: t_amyu[tau:1] (CHoleCan: .~) [W] &_amyE :: t_amyD[tau:1] (CHoleCan: &) [W] lensRules_amyL :: t_amyK[tau:1] (CHoleCan: lensRules)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug : error: Could not find module ‘Control.Exception.Throwable’ It is a member of the hidden package ‘throwable-exceptions-0.1.0.8 @throwable-exceptions-0.1.0 Loaded GHCi configuration from /tmp/ghci30810/ghci-script Prelude Data.Text Data.Char Language.Haskell.TH T TIO> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:57:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:57:01 -0000 Subject: [GHC] #13932: GHCi dumps "panic!" ("initTc: unsolved constraints") In-Reply-To: <046.44594cf92538b428c741afbeb490daf5@haskell.org> References: <046.44594cf92538b428c741afbeb490daf5@haskell.org> Message-ID: <061.91c641f96ab1b162db3ebe5769f0946e@haskell.org> #13932: GHCi dumps "panic!" ("initTc: unsolved constraints") -------------------------------+-------------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by aiya000): ghci says below line if I replace Main.hs (but it was defined) https://gist.github.com/a57b9f85e7927c1327450183faa81620 {{{ *Control.Exception.Throwable.TH Data.Text Data.Char Language.Haskell.TH T TIO> :reload [7 of 9] Compiling Maru.Main ( /home/aiya000/Repository/hs- zuramaru/src/Maru/Main.hs, interpreted ) /home/aiya000/Repository/hs-zuramaru/src/Maru/Main.hs:44:1: error: Variable not in scope: makeLensesA :: Name -> DecsQ Failed, modules loaded: Control.Exception.Throwable.TH, Maru.Eval, Maru.Parser, Maru.Type, Maru.Type.Parser, Maru.Type.SExpr. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 01:59:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 01:59:33 -0000 Subject: [GHC] #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") (was: GHCi dumps "panic!" ("initTc: unsolved constraints")) In-Reply-To: <046.44594cf92538b428c741afbeb490daf5@haskell.org> References: <046.44594cf92538b428c741afbeb490daf5@haskell.org> Message-ID: <061.718072baed0355f7443e58e17418f19a@haskell.org> #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") -------------------------------------+------------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by aiya000): * keywords: ghci => * failure: GHCi crash => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:04:45 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? In-Reply-To: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> References: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> Message-ID: <063.4d7fbfa0b455bcd9629381654524a66c@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:1 goldfire]: >under the substitution `kx1 |-> TyFun kx1 TC` You meant `kx2 |-> TyFun kx1 TC` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:05:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:05:29 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? In-Reply-To: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> References: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> Message-ID: <063.0ec798ca83231d040230a06d96a9e173@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 11715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * status: new => closed * resolution: => duplicate * related: => 11715 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:07:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:07:12 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? In-Reply-To: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> References: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> Message-ID: <063.373bd4328fe9faa384ecca804f8d4229@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * related: 11715 => #11715 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:15:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:15:22 -0000 Subject: [GHC] #13931: GHC incorrectly considers type family instances conflicting? In-Reply-To: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> References: <048.588cf868a4d4adcc1c89da157dc54dbb@haskell.org> Message-ID: <063.de9663078a458382568fec236188ed5f@haskell.org> #13931: GHC incorrectly considers type family instances conflicting? -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No, I meant what I said. I should have included `kx2 |-> kx1` as well, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:26:05 -0000 Subject: [GHC] #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") In-Reply-To: <046.44594cf92538b428c741afbeb490daf5@haskell.org> References: <046.44594cf92538b428c741afbeb490daf5@haskell.org> Message-ID: <061.79ab9c978c6c473f921e9f10dcec8f73@haskell.org> #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") -------------------------------------+------------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by aiya000): I use makeLensesFor instead of my makeLensesA. Is this microlens's problem ? https://github.com/aiya000/hs- zuramaru/commit/3980ea2833fa346592745d1bf15f86f6bb444d88 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:27:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:27:47 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.b57fe8ea8710f10502217b197b8f72fe@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): In the case of a concrete syntax error (as opposed to a type error), I believe that the location of the error is the first character that fails to parse. In the case of the original program, that character is the `m` in the first occurrence of `main`, as reported by GHC. GHC does ''not'' try to find the line where the fix needs to be applied, and I don't think it should, for parse errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 02:57:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 02:57:56 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.bbec7e39ad46e6fe6204c042eb3585c2@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): comment:13 is asking for injectivity from result with ''either'' argument to the other. Notice the O.P. for `AddTF` only considers result & first argument `->` second arg. I see a problem. In instances {{{ type family xs :++: ys = r | r xs -> ys, r ys -> xs where -- both injectivities '[] :++: ys = ys (x ': xs) :++: ys = x ': (xs :++: ys) }}} Under the injection `r ys -> xs`, I think GHC will not be able to see the 'apartness' in the two equations. That is, it won't be able to disprove `ys ~ (x ': (xs :++: ys))`. Yes we know they can't unify, but GHC sees `:++:` as a Type Function, not a (proto-)constructor. Speculative remedy [https://github.com/AntC2/ghc-proposals/blob/instance- apartness-guards/proposals/0000-instance-apartness-guards.rst#injective- type-families proposed here], for the `AddTF` example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 03:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 03:55:49 -0000 Subject: [GHC] #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") In-Reply-To: <046.44594cf92538b428c741afbeb490daf5@haskell.org> References: <046.44594cf92538b428c741afbeb490daf5@haskell.org> Message-ID: <061.bb2876afa2dfb0a0a80c9481f8c5d796@haskell.org> #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") -------------------------------------+------------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2. For what it's worth, this panic sometimes happens when you have out-of- scope identifiers. Here's the error message you get on GHC 8.2: {{{ [6 of 6] Compiling Maru.Main ( src/Maru/Main.hs, interpreted ) src/Maru/Main.hs:42:15: error: • Variable not in scope: makeLensesWith :: t1 -> String -> Name -> DecsQ • Perhaps you meant ‘makeLensesA’ (line 42) Perhaps you want to add ‘makeLensesWith’ to the import list in the import of ‘Lens.Micro.TH’ (src/Maru/Main.hs:26:1-45). | 42 | makeLensesA = makeLensesWith (lensRules & lensField .~ addSuffix) | ^^^^^^^^^^^^^^ src/Maru/Main.hs:42:31: error: • Variable not in scope: lensRules • Perhaps you want to add ‘lensRules’ to the import list in the import of ‘Lens.Micro.TH’ (src/Maru/Main.hs:26:1-45). | 42 | makeLensesA = makeLensesWith (lensRules & lensField .~ addSuffix) | ^^^^^^^^^ src/Maru/Main.hs:42:41: error: Variable not in scope: (&) :: t5 -> (((Name -> [Name] -> Name -> [DefName]) -> f0 (Name -> [Name] -> Name -> [DefName])) -> Lens.Micro.TH.LensRules -> f0 Lens.Micro.TH.LensRules) -> t3 | 42 | makeLensesA = makeLensesWith (lensRules & lensField .~ addSuffix) | ^ src/Maru/Main.hs:42:53: error: • Variable not in scope: (.~) :: t3 -> (Name -> [Name] -> Name -> [DefName]) -> t1 • Perhaps you meant ‘.’ (imported from Prelude) | 42 | makeLensesA = makeLensesWith (lensRules & lensField .~ addSuffix) | ^^ src/Maru/Main.hs:54:1: error: GHC stage restriction: ‘makeLensesA’ is used in a top-level splice, quasi-quote, or annotation, and must be imported, not defined locally | 54 | makeLensesA ''CliOptions | ^^^^^^^^^^^ }}} So ultimately, the root of the issue is that you're trying to use things which aren't imported (e.g., `makeLensesWith`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 04:03:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 04:03:40 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.f447b6edf90a6c1885f15fe4e7b2c41b@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "Smaller-Vector.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 04:04:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 04:04:21 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.e2a7203a565f23af6d2867924c224a01@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "smaller-ds.diff" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 04:07:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 04:07:59 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.80e924473788713fdcd74896c6817540@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I cut down the test case some more, to `Smaller-Vector.hs`, with desugar dump in `smaller-ds.diff`. The relative performance contrast isn't ''quite'' as strong, but it's still almost five times as bad in HEAD as before the badness started. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 06:58:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 06:58:19 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.ea9011b22c93527a0e41c29b6c8293a8@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, goldfire )]]\\ OK. It is preferable to indicate the line where there is the syntax error. And the compiler does so in the majority of cases. Here what is the best solution?\\ If the error is on the line {{{main}}}, do you move {{{main}}} to the right of two spaces? And so you create disorder in your code, or you correct the line above? If you correct the line above, GHC should indicate this line for correction. But perhaps this is too difficult to code?\\ In this specific case what do you suggest? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 08:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 08:02:35 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.ea2094015abf2c2b3ba76a4211de9462@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -26,0 +26,1 @@ + * #13931 New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. See also * #11621 * #12933 * #9547 * #13931 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 10:43:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 10:43:48 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.3a43be5e85dec769ddbe4cfc123e0454@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Are we exploring avenues like [https://ghc.haskell.org/trac/ghc/ticket/6018#comment:48 head-injectivity] or partial injectivity? Richard's example tells us `x ~ Just y` if `F x ~ True` {{{#!hs type family F a where F (Just x) = True F Nothing = False }}} but similarly {{{#!hs type family G a where G (Just x) = (x, x) G Nothing = (Int, Int) }}} means `x ~ Int` if `G (Just x) ~ (Int, Int)` — is that useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 14:55:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 14:55:18 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.4cabdc7c69393141093f605c463f5ee7@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): The correction to the code is irrelevant for parsing errors: GHC just reports where it first encounters a parsing error. There is no promise that a fix is available on that line -- indeed, in this case it's just a stroke of luck that there is. While it's conceivable to imagine some program analysis tool that uses heuristics to do what you want -- make the suggestion an expert Haskeller would make -- that is well beyond the scope of what GHC does. The amount of engineering would be huge. Perhaps this kind of tool would pay off in the long run (imagine always having an "expert Haskeller" at your side while programming!), it doesn't seem necessary to tie such a tool into GHC. So, my recommendation is to treat the current behavior as correct and move onto other problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:26:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:26:51 -0000 Subject: [GHC] #13913: Can't apply higher-ranked kind in type family In-Reply-To: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> References: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> Message-ID: <065.3a0c6d5698d8e6e7fd199625302cae1d@haskell.org> #13913: Can't apply higher-ranked kind in type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe this is a dup of #11719. My recent [https://github.com/ghc- proposals/ghc-proposals/pull/55 proposal] around adding explicit `forall`s to type family equations will introduce a workaround. Perhaps a simple case like this, though, could be made to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:31:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:31:56 -0000 Subject: [GHC] #13913: Can't apply higher-ranked kind in type family In-Reply-To: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> References: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> Message-ID: <065.e8f153484696b226f383ca1eb0fab17e@haskell.org> #13913: Can't apply higher-ranked kind in type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11719 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11719 Comment: Oops, I didn't see that ticket! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:32:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:32:19 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.5c9af39de42fe21e857c049d2f453b3a@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #13913 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:37:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:37:35 -0000 Subject: [GHC] #13909: Can't partially apply a data type with a visible quantifier in its kind In-Reply-To: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> References: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> Message-ID: <065.8af779ef05dcc6a75a38a5b43b276fc3@haskell.org> #13909: Can't partially apply a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 goldfire): Other than the "expecting two more arguments" part (it should be "one", not "two"), this is correct behavior. What you're trying to do would require impredicative polymorphism in kinds, as you want the kind variable `k` to expand to a type involving a `forall`. We can keep this open as an example of a misphrased error message, but rejection is the correct action until we have impredicativity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:39:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:39:02 -0000 Subject: [GHC] #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind (was: Can't partially apply a data type with a visible quantifier in its kind) In-Reply-To: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> References: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> Message-ID: <065.ae464385fe33f74224e90cb2e69089b0@haskell.org> #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 15:48:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 15:48:06 -0000 Subject: [GHC] #13739: very slow linking of executables with ld.bfd < 2.27 In-Reply-To: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> References: <043.2d2650cd128632597774b5afb6c7a225@haskell.org> Message-ID: <058.80a663e91fae2a6bf3188041e5b3145a@haskell.org> #13739: very slow linking of executables with ld.bfd < 2.27 -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13541 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: 13541 => #13541 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 16:40:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 16:40:38 -0000 Subject: [GHC] #13884: To an automatic compilation of file-header LANGUAGE pragmas in GHC. In-Reply-To: <044.5438e0b55f2f96ccdf324b161ad363cb@haskell.org> References: <044.5438e0b55f2f96ccdf324b161ad363cb@haskell.org> Message-ID: <059.2c6611277d74e5eccb7713efe9cb124a@haskell.org> #13884: To an automatic compilation of file-header LANGUAGE pragmas in GHC. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: If you wish to get a wider opinion from the committee, I suggest you make a ghc-proposal using the established process that we have pointed you to in the past. This is a user-facing change and thus must go through that process. If the proposal is accepted by the committee, we can reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 16:49:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 16:49:55 -0000 Subject: [GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families In-Reply-To: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> References: <050.9aec2c0b0f1e57bc955033f5ea3e1669@haskell.org> Message-ID: <065.00c68aa8e7807722fd01273c2c9c8177@haskell.org> #13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This isn't so easy. With type families, there are potentially many right- hand sides. Some may have polymorphism, and some may not. And we might not know which is chosen until we get to the constraint solver. When the constraint-generation algorithm looks at something with type `Foo`, does it add a wrapper for instantiating `forall a. Maybe a`? Or not? Impossible to know. This all smells a bit like impredicativity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:25:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:25:00 -0000 Subject: [GHC] #13884: To an automatic compilation of file-header LANGUAGE pragmas in GHC. In-Reply-To: <044.5438e0b55f2f96ccdf324b161ad363cb@haskell.org> References: <044.5438e0b55f2f96ccdf324b161ad363cb@haskell.org> Message-ID: <059.4cebb3525e97c3782537772dc46728fa@haskell.org> #13884: To an automatic compilation of file-header LANGUAGE pragmas in GHC. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: wontfix => Comment: Replying to [[span(style=color: #FF0000, goldfire )]]\\ This idea is an idea and someone could take it up for study. Once again goldfire you are not alone. The others have the right as much as you to read this ticket and make their choice. This ticket is for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:35:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:35:54 -0000 Subject: [GHC] #13871: GHC panic in 8.2 only: typeIsTypeable(Coercion) In-Reply-To: <050.f1a0fc44d1ac315eabed1b0be5437302@haskell.org> References: <050.f1a0fc44d1ac315eabed1b0be5437302@haskell.org> Message-ID: <065.0b28abff89b27f61df0e0c8a1e93cf40@haskell.org> #13871: GHC panic in 8.2 only: typeIsTypeable(Coercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeInType, Resolution: fixed | Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13871 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3671, Wiki Page: | Phab:D3672 -------------------------------------+------------------------------------- Comment (by goldfire): I take it as an eventual goal to have ''all'' types be `Typeable`. Is there a ticket requesting support for types with casts/coercions? I don't think it would be terribly hard to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:38:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:38:02 -0000 Subject: [GHC] #13917: The line on which to locate the error indication is bad. In-Reply-To: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> References: <044.192a9adb4023df4653daed7b377e44a6@haskell.org> Message-ID: <059.eb19876fce7f0542395a6f416fc442cd@haskell.org> #13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, goldfire )]]\\ No, here it is not a matter of doing an analysis by the compiler. Here we find ourselves in a situation that no one imagined except me. And it seems that you do not understand this situation and that it does not interest you. It's amazing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:41:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:41:24 -0000 Subject: [GHC] #13908: sameMutableArray equivalent for Array In-Reply-To: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> References: <045.5ef205d18514bb5c85c11020f7eec5af@haskell.org> Message-ID: <060.f69b235260a27c400247ee2ffb12dde7@haskell.org> #13908: sameMutableArray equivalent for Array -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3697 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, in its current form I realized that `reallyUnsafePtrEquality#` doesn't really fit the bill: it's type is `Type -> Type -> Int#` whereas `ByteArray#` is of kind `TYPE 'UnliftedPtrRep`. This means that you would first need to coerce the `ByteArray#` to a lifted type before being able to do the comparison, which seems quite ugly. Ideally we would be able to make the type of `reallyUnsafePtrEquality#` `TYPE ('PtrRep levity) -> TYPE ('PtrRep levity) -> Int#`, abstracting over levity. In the short term we could also introduce a `reallyUnsafeUnliftedPtrEquality# :: TYPE 'UnliftedPtrRep -> TYPE 'UnliftedPtrRep -> Int#`, but frankly I think the `unsafeCoerce#` is probably a reasonable 80% solution for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:54:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:54:50 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.217e2df964b30cb73928189c4fe749b8@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 goldfire): You want impredicativity. But you can't have it. :) The problem is more visible when we expand your `Typeable t` constraint to write explicitly the kind argument: `Typeable (forall k. k -> Type) t`, which uses a polytype to instantiate a datatype parameter. I'm afraid I don't have a workaround to suggest... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 17:56:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 17:56:30 -0000 Subject: [GHC] #13871: GHC panic in 8.2 only: typeIsTypeable(Coercion) In-Reply-To: <050.f1a0fc44d1ac315eabed1b0be5437302@haskell.org> References: <050.f1a0fc44d1ac315eabed1b0be5437302@haskell.org> Message-ID: <065.88cca44dab0dc3f004ca700b93ec3c35@haskell.org> #13871: GHC panic in 8.2 only: typeIsTypeable(Coercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeInType, Resolution: fixed | Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13871 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3671, Wiki Page: | Phab:D3672 -------------------------------------+------------------------------------- Comment (by bgamari): I don't believe there is one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:42:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:42:14 -0000 Subject: [GHC] #13933: Support Typeable instances for types with coercions Message-ID: <047.2f51ec97795d85d670d1916471772452@haskell.org> #13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE GADTs, TypeApplications, TypeInType #-} module Bug where import Type.Reflection data G a where MkG :: a ~ Bool => G a rep = typeRep @MkG }}} I get {{{ Bug.hs:10:7: error: • No instance for (Typeable <>) arising from a use of ‘typeRep’ • In the expression: typeRep @MkG In an equation for ‘rep’: rep = typeRep @MkG | 10 | rep = typeRep @MkG | }}} First off, the error message is confusing, mentioning the mysterious `<>`. But more importantly, it would be nice if the `Typeable` mechanism supported coercions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:48:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:48:00 -0000 Subject: [GHC] #12087: Inconsistency in GADTs? In-Reply-To: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> References: <051.271b252c8ff7e6b4a86908e0694bb2a9@haskell.org> Message-ID: <066.97bfb1552d32bea6575e39ba39c98447@haskell.org> #12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The underlying issue here -- that the type of GADT constructors is a bit inflexible -- is important in the context of Dependent Haskell. For example, I might want to say {{{#!hs data Foo a where MkFoo :: pi (x :: Type) -> (F x ~ Bool) => Foo x }}} This takes a ''visible'' type `x` and then asserts some constraint on `x`. The constraint must come ''after'' binding `x`, of course! So loosening up these rules will actually increase expressiveness once we have dependent types. Re comment:5, recall that `:type` takes an ''expression'', upon which it performs type inference. Thus it stands to reason that quantifiers, etc., will get shuffled around. This is why `:type +v` got added, so that the type is just reported as is, without any instantiation/regeneralization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:55:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:55:07 -0000 Subject: [GHC] #13872: Strange Typeable error message involving TypeInType In-Reply-To: <050.3b6072a1389bdaa345d0cbeac9135be1@haskell.org> References: <050.3b6072a1389bdaa345d0cbeac9135be1@haskell.org> Message-ID: <065.cd705fd57d24ea60a29b79c49b6375ac@haskell.org> #13872: Strange Typeable error message involving TypeInType -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: duplicate | Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13933 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13933 Comment: Closing in favor of #13933. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:55:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:55:26 -0000 Subject: [GHC] #13933: Support Typeable instances for types with coercions In-Reply-To: <047.2f51ec97795d85d670d1916471772452@haskell.org> References: <047.2f51ec97795d85d670d1916471772452@haskell.org> Message-ID: <062.3e0e81c0ded8b3a1507303fc0b44073f@haskell.org> #13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13872 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13872 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:56:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:56:17 -0000 Subject: [GHC] #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) In-Reply-To: <051.6f4adb265ab208b75b739851f1fb480c@haskell.org> References: <051.6f4adb265ab208b75b739851f1fb480c@haskell.org> Message-ID: <066.42ac12540423b2867b4fc41741f515d9@haskell.org> #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: GADTs, Resolution: | ScopedTypeVariables 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 goldfire): I frequently find this behavior of GHC frustrating, though I fully understand why it works the way it does (and indeed don't propose a change). Perhaps the way forward is to obviate the need for such signatures by introducing visible type patterns, #11350. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 18:57:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 18:57:16 -0000 Subject: [GHC] #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist Message-ID: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | 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: -------------------------------------+------------------------------------- Trying to pass `--target=arm-linux-gnueabihf` to a ARM 8.0.2 bindist's `configure` on my AArch64 box fails with, {{{ $ ./configure --prefix=/mnt/ext/arm/roots/ghc/8.0.1-armv7 --target=arm- linux-gnueabihf checking for path to top of build tree... /mnt/ext/arm/ghc-8.0.2 Build platform inferred as: arm-unknown-linux Host platform inferred as: arm-unknown-linux Unknown CPU }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 19:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 19:06:30 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.bd427de2a618e35a5a8740c43516fcce@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 RyanGlScott): Interesting. Simon once [https://mail.haskell.org/pipermail/ghc- devs/2016-September/012824.html commented] that using `TypeApplications` to call a polymorphic function at a polymorphic type fell under a safe subset of `ImpredicativeTypes` (that ought not require bringing in the other baggage that `ImpredicativeTypes` implies). If we had this capability, would `Typeable @(forall k. k -> Type) t` be a thought GHC could think? (I realize that we don't yet have visible kind applications, but you get the idea.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 19:21:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 19:21:00 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.7492ef38a345321f1863b1091ef3ac4f@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 goldfire): Yes, that would work nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 20:11:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 20:11:20 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.79b16928aee108883b4d1aedd9ad4077@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ak3n): I am not sure, but I think that it's enough to change `pprName' Alone` to `pprName' Applied` [https://git.haskell.org/ghc.git/blob/HEAD:/libraries /template-haskell/Language/Haskell/TH/PprLib.hs#l123 here]. There are 8 failed tests in `testsuite/tests/th` because of this change: - `GHC.Types.:` becomes `(GHC.Types.:)` - `Data.Type.Equality.~` becomes `(Data.Type.Equality.~)` - and something else There is another way to fix it. Change `ppr t` to `pprName' Applied t` [https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template- haskell/Language/Haskell/TH/Ppr.hs#l401 here], which outputs: {{{ data (:~:_0) a_1 b_2 where Refl1_3 :: :~:_0 a_4 a_4 data (:~~:_0) a_1 b_2 = a_1 ~ b_2 => Refl2_3 }}} This [https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template- haskell/Language/Haskell/TH/Ppr.hs#l402 line] is responsible for the kind of `Refl1_3`, but I haven't figured out how to fix it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 20:39:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 20:39:41 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.f0fcc6ab4b5f41bcea1c3f97795b0027@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for looking into this, ak3n! I don't believe changing the implementation of `pprName` is what you want here, since that will affect far more than just infix datatypes names, which is what you really care about. I think your second suggestion (changing uses of `ppr` to `pprName' Applied`) is on the right track. As far as why the type of `Refl1_3` is pretty-printed incorrectly, I //think// it's due to the pretty-printer for `Type`. It has a case for `ConT` [https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template- haskell/Language/Haskell/TH/Ppr.hs#l682 here]: {{{#!hs pprParendType (ConT c) = ppr c }}} I think this should be `pprName' Applied c` instead. This is consistent with the pretty-printer's [https://git.haskell.org/ghc.git/blob/3c4537ea1c940966eddcb9cb418bf8e39b8f0f1c:/libraries /template-haskell/Language/Haskell/TH/Ppr.hs#l128 treatment] for `Exp` as well: {{{#!hs pprExp _ (ConE c) = pprName' Applied c }}} So that feels like the right solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 21:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 21:02:43 -0000 Subject: [GHC] #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail Message-ID: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail -------------------------------------+------------------------------------- Reporter: mjvoge02 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: autoconf, | Operating System: Linux AC_CHECK_FUNC, configure, nixos | Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Code in [[GhcFile(configure.ac)]] incorrectly assesses that pthread functions will be available without explicitly providing `-lpthread` to gcc. This causes the build to fail. Forcing `need_lpthread=1` in [[GhcFile(configure.ac)]] causes the build to succeed and produce a perfectly functional GHC. From conversation on #GHC: "It looks like the combination of the following two commits has caused the breakage: e94bfb677298de3c4b4e0d1223fbc589849b79be, c0872bf99ff891e440f118bf9eea20b980c2cfca.[[br]] The first makes the configure script check if the `-lpthread` argument is required when building GHC, and the second uses that knowledge at runtime to decide whether to pass `-lpthread` when linking programs. [[br]] Stage 0 builds stage 1 just fine, since it doesn't have these commits and decides whether to pass `-lpthread` based purely on the platform. But the code from the first commit is yielding a false result (I don't know why), so stage 1 fails to build stage 2, since the second commit makes it use the false result to choose not to pass `-lpthread`." Also, doesn't determining the need for `-lpthread` like this have problematic implications for cross compilation? Whether `-lpthread` is required could be different between linking GHC and GHC doing linking (e.g. a cross compiler built on a system that does need the flag targeting a system that doesn't.) Ignoring that, using AX_PTHREAD or ACX_PTHREAD could potentially help resolve the issue. Relevant code from [[GhcFile(configure.ac)]]: {{{#!bash dnl Some platforms (e.g. Android's Bionic) have pthreads support available dnl without linking against libpthread. Check whether -lpthread is necessary dnl to use pthreads. dnl dnl Note that it is important that this happens before we AC_CHECK_LIB(thread) AC_MSG_CHECKING(whether -lpthread is needed for pthreads) AC_CHECK_FUNC(pthread_create, [ AC_MSG_RESULT(no) need_lpthread=0 ], [ AC_CHECK_LIB(pthread, pthread_create, [ AC_MSG_RESULT(yes) need_lpthread=1 ], [ AC_MSG_RESULT([no pthreads support found.]) need_lpthread=0 ]) ]) AC_DEFINE_UNQUOTED([NEED_PTHREAD_LIB], [$need_lpthread], [Define 1 if we need to link code using pthreads with -lpthread]) }}} System information: Linux nixos 4.9.30 x86_64 GNU/Linux gcc 5.4.0 ghc 7.10.3 Attempting to build GHC HEAD fails with {{{#!bash ... "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit- id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc- DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O0 -no- user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/hsSyn/HsTypes.hs -o compiler/stage2/build/HsTypes.o -dyno compiler/stage2/build/HsTypes.dyn_o includes/rts/OSThreads.h:58:0: error: error: undefined reference to 'pthread_mutex_trylock' | 58 | return pthread_mutex_trylock(mutex); | ^ includes/rts/OSThreads.h:58:0: error: error: undefined reference to 'pthread_mutex_trylock' | 58 | return pthread_mutex_trylock(mutex); | ^ rts/posix/OSThreads.c:137:0: error: error: undefined reference to 'pthread_create' | 137 | int result = pthread_create(pId, NULL, (void *(*)(void *))startProc, param); | ^ rts/posix/OSThreads.c:139:0: error: error: undefined reference to 'pthread_detach' | 139 | pthread_detach(*pId); | ^ rts/posix/OSThreads.c:141:0: error: error: undefined reference to 'pthread_setname_np' | 141 | pthread_setname_np(*pId, name); | ^ rts/posix/OSThreads.c:184:0: error: error: undefined reference to 'pthread_key_create' | 184 | if ((r = pthread_key_create(key, NULL)) != 0) { | ^ rts/posix/OSThreads.c:203:0: error: error: undefined reference to 'pthread_setspecific' | 203 | if ((r = pthread_setspecific(*key,value)) != 0) { | ^ rts/posix/OSThreads.c:212:0: error: error: undefined reference to 'pthread_key_delete' | 212 | if ((r = pthread_key_delete(*key)) != 0) { | ^ rts/posix/OSThreads.c:233:0: error: error: undefined reference to 'pthread_create' | 233 | int result = pthread_create(&tid, NULL, | ^ rts/posix/OSThreads.c:236:0: error: error: undefined reference to 'pthread_detach' | 236 | pthread_detach(tid); | ^ rts/posix/OSThreads.c:192:0: error: error: undefined reference to 'pthread_getspecific' | 192 | return pthread_getspecific(*key); | ^ rts/posix/OSThreads.c:371:0: error: error: undefined reference to 'pthread_kill' | 371 | pthread_kill(id, SIGPIPE); | ^ rts/posix/itimer/Pthread.c:171:0: error: error: undefined reference to 'pthread_create' | 171 | if (! pthread_create(&thread, NULL, itimer_thread_func, (void*)handle_tick)) { | ^ rts/posix/itimer/Pthread.c:210:0: error: error: undefined reference to 'pthread_join' | 210 | if (pthread_join(thread, NULL)) { | ^ rts/posix/itimer/Pthread.c:173:0: error: error: undefined reference to 'pthread_setname_np' | 173 | pthread_setname_np(thread, "ghc_ticker"); | ^ rts/posix/itimer/Pthread.c:214:0: error: error: undefined reference to 'pthread_detach' | 214 | pthread_detach(thread); | ^ includes/rts/OSThreads.h:58:0: error: error: undefined reference to 'pthread_mutex_trylock' | 58 | return pthread_mutex_trylock(mutex); | ^ collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) make[1]: *** [iserv/ghc.mk:72: iserv/stage2/build/tmp/ghc-iserv] Error 1 make[1]: *** Waiting for unfinished jobs.... <> <> <> <> make: *** [Makefile:127: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 21:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 21:24:14 -0000 Subject: [GHC] #8033: add AVX register support to llvm calling convention In-Reply-To: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> References: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> Message-ID: <060.4130078f52cfe073f81d4484549a13d9@haskell.org> #8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett@… (added) Comment: The patch has been accepted and will hopefully be merged shortly. I'll flip on the GHC calling conventions bits by default in HEAD once this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 22:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 22:31:38 -0000 Subject: [GHC] #13936: initTc: unsolved constraints Message-ID: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> #13936: initTc: unsolved constraints --------------------------------------+--------------------------------- Reporter: junkbondtrader | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ Prelude> lucky (7.0 :: Num) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] lucky_afgR :: t_afgQ[tau:1] (CHoleCan: lucky) [W] lucky_afhl :: t_afhk[tau:1] (CHoleCan: lucky)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs lucky :: Num -> String lucky 7 = "LUCKY NUMBER SEVEN!" lucky x = "Sorry, you're out of luck, pal!" }}} I believe that above function declaration doesn't actually make sense, but it caused a panic that asked for a bug report so I'm doing it. Apologies for my newness :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 22:32:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 22:32:55 -0000 Subject: [GHC] #13936: initTc: unsolved constraints In-Reply-To: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> References: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> Message-ID: <068.98a0410963549f8d0415c778997706b7@haskell.org> #13936: initTc: unsolved constraints -----------------------------------+-------------------------------------- Reporter: junkbondtrader | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by junkbondtrader: @@ -19,3 +19,3 @@ - I believe that above function declaration doesn't actually make sense, but - it caused a panic that asked for a bug report so I'm doing it. Apologies - for my newness :) + I believe that the function declaration and invocation about don't + actually make sense, but they caused a panic that asked for a bug report + so I'm doing it. Apologies for my newness :) New description: {{{ Prelude> lucky (7.0 :: Num) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] lucky_afgR :: t_afgQ[tau:1] (CHoleCan: lucky) [W] lucky_afhl :: t_afhk[tau:1] (CHoleCan: lucky)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs lucky :: Num -> String lucky 7 = "LUCKY NUMBER SEVEN!" lucky x = "Sorry, you're out of luck, pal!" }}} I believe that the function declaration and invocation about don't actually make sense, but they caused a panic that asked for a bug report so I'm doing it. Apologies for my newness :) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 22:33:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 22:33:11 -0000 Subject: [GHC] #13936: initTc: unsolved constraints In-Reply-To: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> References: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> Message-ID: <068.2a29d05bad8a44b7367947552cb8dc5b@haskell.org> #13936: initTc: unsolved constraints -----------------------------------+-------------------------------------- Reporter: junkbondtrader | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by junkbondtrader: @@ -19,1 +19,1 @@ - I believe that the function declaration and invocation about don't + I believe that the function declaration and invocation above don't New description: {{{ Prelude> lucky (7.0 :: Num) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] lucky_afgR :: t_afgQ[tau:1] (CHoleCan: lucky) [W] lucky_afhl :: t_afhk[tau:1] (CHoleCan: lucky)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs lucky :: Num -> String lucky 7 = "LUCKY NUMBER SEVEN!" lucky x = "Sorry, you're out of luck, pal!" }}} I believe that the function declaration and invocation above don't actually make sense, but they caused a panic that asked for a bug report so I'm doing it. Apologies for my newness :) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 22:56:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 22:56:34 -0000 Subject: [GHC] #13937: @progbits is used incorrectly throughout GHC Message-ID: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> #13937: @progbits is used incorrectly throughout GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- GHC uses `.section $SECTION_NAME,$FLAGS, at progbits` directives throughout its produced assembler. However, some architectures (e.g. ARM) use `@` as a comment character and therefore must use some other prefix for section types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 22:58:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 22:58:43 -0000 Subject: [GHC] #13936: initTc: unsolved constraints In-Reply-To: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> References: <053.bc2d2affd435a35c80c47944c92f4068@haskell.org> Message-ID: <068.36e7fd39f797492b40d49ee9f0e12552@haskell.org> #13936: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: junkbondtrader | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * os: Windows => Unknown/Multiple * resolution: => duplicate * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #13106 Comment: Thanks for the bug report. I believe this is a duplicate of #13106, which has been fixed in GHC 8.2.1. I don't know what `Num` type you're using here, so I can't confirm that it's fixed in 8.2.1 myself - please reopen if this issue persists in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:02:44 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.8fcefec1f8b0ef4c1b1f781dd4d60c01@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"bd4fdc6aa34a85268f3e9a2bd3f4142a97724ce4/ghc" bd4fdc6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd4fdc6aa34a85268f3e9a2bd3f4142a97724ce4" Implement split-sections support for windows. Summary: Initial implementation of split-section on Windows. This also corrects section namings and uses the platform convention of `$` instead of `.` to separate sections. Implementation is based on @awson's patches to binutils. Binutils requires some extra help when compiling the libraries for GHCi usage. We drop the `-T` and use implicit scripts to amend the linker scripts instead of replacing it. Because of these very large GHCi object files, we need big-obj support, which will be added by another patch. Test Plan: ./validate Reviewers: awson, austin, bgamari Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3383 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:06:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:06:49 -0000 Subject: [GHC] #13937: @progbits is used incorrectly throughout GHC In-Reply-To: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> References: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> Message-ID: <061.86079b2b0390624269aa7cb685c70983@haskell.org> #13937: @progbits is used incorrectly throughout GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3712 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3712 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:08:43 -0000 Subject: [GHC] #13937: @progbits is used incorrectly throughout GHC In-Reply-To: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> References: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> Message-ID: <061.bfb81f740045d0b93825b8e4da14de69@haskell.org> #13937: @progbits is used incorrectly throughout GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3712 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is documented in the [[https://sourceware.org/binutils/docs/as/Section.html|GNU as documentation]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:33:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:33:48 -0000 Subject: [GHC] #13938: Iface type variable out of scope: k1 Message-ID: <050.7a3f2d444543ff2efcc9028549798245@haskell.org> #13938: Iface type variable out of scope: k1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I managed to make GHC spit out an unusual warning when doing some dependent Haskell recently. This issue is reproducible on GHC 8.0.1, 8.0.2, 8.2.1, and HEAD. You'll need these two files: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Eliminator where import Data.Kind (Type) data family Sing (a :: k) data instance Sing (z :: [a]) where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x:xs) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ data FunArrow = (:->) -- ^ '(->)' | (:~>) -- ^ '(~>)' class FunType (arr :: FunArrow) where type Fun (k1 :: Type) arr (k2 :: Type) :: Type class FunType arr => AppType (arr :: FunArrow) where type App k1 arr k2 (f :: Fun k1 arr k2) (x :: k1) :: k2 type FunApp arr = (FunType arr, AppType arr) instance FunType (:->) where type Fun k1 (:->) k2 = k1 -> k2 $(return []) -- This is only necessary for GHC 8.0 -- GHC 8.2 is smarter instance AppType (:->) where type App k1 (:->) k2 (f :: k1 -> k2) x = f x instance FunType (:~>) where type Fun k1 (:~>) k2 = k1 ~> k2 $(return []) instance AppType (:~>) where type App k1 (:~>) k2 (f :: k1 ~> k2) x = f @@ x infixr 0 -?> type (-?>) (k1 :: Type) (k2 :: Type) (arr :: FunArrow) = Fun k1 arr k2 elimList :: forall (a :: Type) (p :: [a] -> Type) (l :: [a]). Sing l -> p '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> p xs -> p (x:xs)) -> p l elimList = elimListPoly @(:->) elimListTyFun :: forall (a :: Type) (p :: [a] ~> Type) (l :: [a]). Sing l -> p @@ '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> p @@ xs -> p @@ (x:xs)) -> p @@ l elimListTyFun = elimListPoly @(:~>) @_ @p elimListPoly :: forall (arr :: FunArrow) (a :: Type) (p :: ([a] -?> Type) arr) (l :: [a]). FunApp arr => Sing l -> App [a] arr Type p '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> App [a] arr Type p xs -> App [a] arr Type p (x:xs)) -> App [a] arr Type p l elimListPoly SNil pNil _ = pNil elimListPoly (SCons x (xs :: Sing xs)) pNil pCons = pCons x xs (elimListPoly @arr @a @p @xs xs pNil pCons) }}} {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module ListSpec where import Eliminator import Data.Kind import Data.Type.Equality import GHC.TypeLits type family Length (l :: [a]) :: Nat where {} type family Map (f :: a ~> b) (l :: [a]) :: [b] where {} type WhyMapPreservesLength (f :: x ~> y) (l :: [x]) = Length l :~: Length (Map f l) data WhyMapPreservesLengthSym1 (f :: x ~> y) :: [x] ~> Type type instance Apply (WhyMapPreservesLengthSym1 f) l = WhyMapPreservesLength f l mapPreservesLength :: forall (x :: Type) (y :: Type) (f :: x ~> y) (l :: [x]). Length l :~: Length (Map f l) mapPreservesLength = elimListTyFun @x @(WhyMapPreservesLengthSym1 f) @l undefined undefined undefined }}} You'll need to compile the files like this: {{{ $ /opt/ghc/8.0.2/bin/ghc -fforce-recomp -O2 -c Eliminator.hs $ /opt/ghc/8.0.2/bin/ghc -fforce-recomp -O2 -c ListSpec.hs ./Eliminator.hi Declaration for elimListTyFun Unfolding of elimListTyFun: Iface type variable out of scope: k2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:38:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:38:13 -0000 Subject: [GHC] #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail In-Reply-To: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> References: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> Message-ID: <062.de022b54c0fbbd7e064f0760b350c041@haskell.org> #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail -------------------------------------+------------------------------------- Reporter: mjvoge02 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: autoconf, | AC_CHECK_FUNC, configure, nixos Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: => 8.2.1 Comment: I believe this was fixed by Phab:D3694, which is present in GHC 8.2.1-rc3. Let me know if it's fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:40:30 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.ed372a16a7db1a5d3185f30a2bfe89aa@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:51:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:51:51 -0000 Subject: [GHC] #13702: GHC can't produce position independent executables In-Reply-To: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> References: <046.3c2d010e4ff43df6076d32ac62165117@haskell.org> Message-ID: <061.e9ed1ae15f46ae34aa2fd8c3563cb4ed@haskell.org> #13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3589 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:55:20 -0000 Subject: [GHC] #11954: Associated pattern synonyms not included in haddock In-Reply-To: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> References: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> Message-ID: <061.e2c86debd30308d3ac8df9b11f762313@haskell.org> #11954: Associated pattern synonyms not included in haddock -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 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): Replying to [comment:8 darchon]: > Hopefully https://github.com/haskell/haddock/commit/87c551fc668b9251f2647cce8772f205e1cee154, which is in haddock's master branch, can still be included for the 8.2.1 release. GHC HQ prefers to ship only ''released'' packages. If Haddock can make a release real quick, we ''might'' be able to slip that change in under the wire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:59:00 -0000 Subject: [GHC] #13930: Cabal configure In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.a2aaabf18d0d7be898ea3f7a274e701d@haskell.org> #13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => Runtime performance bug * milestone: => 8.4.1 Comment: The first bad commit here is, {{{ commit 751996e90a964026a3f86853338f10c82db6b610 Author: Simon Peyton Jones Date: Fri Apr 7 17:10:07 2017 +0100 Kill off complications in CoreFVs When doing type-in-type, Richard introduce some substantial complications in CoreFVs, gathering types and free variables of type. In Trac #13160 we decided that this complication was unnecessary, so this patch removes it. ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 7 23:59:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Jul 2017 23:59:55 -0000 Subject: [GHC] #13930: Cabal configure regresses in runtime (was: Cabal configure) In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.76779d9c45cce5542d6892bf42effbfb@haskell.org> #13930: Cabal configure regresses in runtime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 00:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 00:00:07 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time (was: Cabal configure regresses in runtime) In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.f19896bd36728ccd90747538a4eeca19@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 01:08:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 01:08:53 -0000 Subject: [GHC] #11954: Associated pattern synonyms not included in haddock In-Reply-To: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> References: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> Message-ID: <061.57e752ceab6ec32604b7a5e7f8a1ad9d@haskell.org> #11954: Associated pattern synonyms not included in haddock -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This commit is present in 8.2-rc3. Thanks for updating the milestone, darchon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 01:16:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 01:16:36 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.217f506bde6359499c8cd853b987d429@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The crash appears to happen in `hsIsClosed` called from `isDead`; `killer` is never run. Specifically, my instrumented testcase shows, {{{ $ ./main maker maker maker maker maker isDead Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 01:34:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 01:34:44 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.f3b0f1ecd834e69c9562c97bded11eec@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is my analysis of `stg_takeMVarzh` for future reference, {{{ stg_takeMVarzh: // $rbx = mvar <+0>: mov (%rbx),%rax // $rax = info = GET_INFO(mvar) <+3>: cmpq $0x94f128,0x18(%rbx) // if (StgMVar_value(mvar) == stg_END_TSO_QUEUE_closure) <+11>: je 0x6ec277 // { jump; } (not taken) <+17>: mov %rbx,%rcx <+20>: mov 0x18(%rbx),%rdx // $rdx = val = StgMVar_value(mvar) <+24>: mov 0x8(%rbx),%rbx // $rbx = q = StgMVar_head(mvar) <+28>: cmp $0x94f128,%rbx // if (q == stg_END_TSO_QUEUE_closure) <+35>: je 0x6ec236 // { jump; } (not taken) <+41>: cmpq $0x6ed310,(%rbx) // if (StgHeader_info(q) == stg_IND_info) // ^ crashes here <+48>: je 0x6ec22d // { jump; } <+54>: cmpq $0x6ed938,(%rbx) // if (StgHeader_info(q) == stg_MSG_NULL_info) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 01:54:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 01:54:29 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.c4fcba6566bd43244db404267340d613@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Something slightly suspicious that I hadn't noticed earlier: compiling `Bracket` with `-dcmm-lint` seems to loop the compiler (or hits a very large stack explosion). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 06:23:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 06:23:48 -0000 Subject: [GHC] #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") In-Reply-To: <046.44594cf92538b428c741afbeb490daf5@haskell.org> References: <046.44594cf92538b428c741afbeb490daf5@haskell.org> Message-ID: <061.e6881415314727ff1a2ea0164ab9342f@haskell.org> #13932: GHC and GHCi dumps "panic!" ("initTc: unsolved constraints") -------------------------------------+------------------------------------- Reporter: aiya000 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aiya000): Thanks ! and sorry x) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 07:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 07:07:01 -0000 Subject: [GHC] #13939: Fix and enable SplitSections on 32bit Windows Message-ID: <044.e5aa8e77eb400141c2c1c362c6393b1e@haskell.org> #13939: Fix and enable SplitSections on 32bit Windows --------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #12913 Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- Current split sections is disabled on 32bit windows because there's no bigobj support in binutils 32bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 07:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 07:08:12 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.bb25b1360e60c8bcb8e3f19ea05e0aaf@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * related: #8405 => #8405 #13939 Comment: Created a separate issue for the 32bit binutils problems #13939 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 07:08:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 07:08:28 -0000 Subject: [GHC] #13939: Fix and enable SplitSections on 32bit Windows In-Reply-To: <044.e5aa8e77eb400141c2c1c362c6393b1e@haskell.org> References: <044.e5aa8e77eb400141c2c1c362c6393b1e@haskell.org> Message-ID: <059.9ff191c5aea07182aef4d463c306b333@haskell.org> #13939: Fix and enable SplitSections on 32bit Windows ---------------------------------+-------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12913 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------- Changes (by Phyx-): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 08:52:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 08:52:47 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.f8f2bacdbe1114fbbe517b1d08d1f7d9@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ak3n): Yep, I tried to run the whole test suite and it finished with 417 unexpected failures. Thanks for pointing out `pprParendType`! I didn't find it yesterday. Also, should we change `pprParendType (VarT v) = ppr v` too? Because of `pprExp _ (VarE v) = pprName' Applied v`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 08:57:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 08:57:08 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.ebb3c2340167ca1ec08d93cd7bf36b95@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: (none) => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 09:17:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 09:17:47 -0000 Subject: [GHC] #13940: Reduce duplicate implementations of argument handling on Windows Message-ID: <047.8342ee8748562facc1285d21ddca3123@haskell.org> #13940: Reduce duplicate implementations of argument handling on Windows ----------------------------------------+--------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Keywords: unicode windows | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #12870 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On windows we currently ignore arguments to hs_init/main's argv and instead get the arguments from the windows api when they are requested from the Haskell side. This means * Passing custom arguments to hs_init when not using hs_main might behave unexpected (The haskell und RTS side see different arguments). * Duplication of code to simulate filtering of Arguments by the RTS on the Haskell side. * Behavior between Linux and Windows might differ as result of the above (eg #13287) Instead we can get the UTF16 encoded arguments inside of hs_main from the windows API and pass them along to the RTS UTF8-encoded. This allows argument handling to be fairly uniform between Linux and Windows and enables us to accept hs_init arguments on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 09:18:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 09:18:01 -0000 Subject: [GHC] #13940: Reduce duplicate implementations of argument handling on Windows In-Reply-To: <047.8342ee8748562facc1285d21ddca3123@haskell.org> References: <047.8342ee8748562facc1285d21ddca3123@haskell.org> Message-ID: <062.b4fff4082b095a1e2846647f91326327@haskell.org> #13940: Reduce duplicate implementations of argument handling on Windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Resolution: | Keywords: unicode | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12870 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 14:38:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 14:38:26 -0000 Subject: [GHC] #13941: STG linter's type equality can loop Message-ID: <046.4184638e601895ab74015b9135b0dc45@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- `stgEqType` will currently loop when given the following, {{{#!hs stgEqType (a -> IO ()) (a -> IO ()) }}} The problem is that the `(->)` tycon now takes runtime rep arguments. To see why, let's look at the (paraphrased) implementation, {{{#!hs stgEqType orig_ty1 orig_ty2 = gos (typePrimRep orig_ty1) (typePrimRep orig_ty2) where gos :: [PrimRep] -> [PrimRep] -> Bool gos [_] [_] = go orig_ty1 orig_ty2 gos reps1 reps2 = reps1 == reps2 go :: UnaryType -> UnaryType -> Bool go ty1 ty2 | Just (tc1, tc_args1) <- splitTyConApp_maybe ty1 , Just (tc2, tc_args2) <- splitTyConApp_maybe ty2 , let res = if tc1 == tc2 then equalLength tc_args1 tc_args2 && and (zipWith (gos `on` typePrimRep) tc_args1 tc_args2) else (isFamilyTyCon tc1 || isFamilyTyCon tc2) = res | otherwise = True -- Conservatively say "fine". }}} Our example will begin by looking at the `gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)` and, seeing that the `orig_ty`s are unary, enter `go`. We will then split the applications such that, {{{ tc1, tc2 = (->) tc_args1, tc_args2 = ['LiftedPtrRep, 'LiftedPtrRep, a, IO ()] }}} Seeing that the tycons are equal, we will enter `gos` on each of the `tc_args`. Of course, one would think that `typePrimRep 'LiftedPtrRep` should throw an error, but because `gos` only forces the spine of the list, that error doesn't get thrown. Instead we incorrectly conclude that `'LiftedPtrRep` is a unary type and recurse into `go orig_ty1 orig_ty2`, thus looping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 14:41:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 14:41:11 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.c164d71f29e29cde0de9460b08d1075f@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 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 bgamari): For the record, I discovered this while looking at #13916. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 14:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 14:45:06 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.204be1702a0607ecab8ac3577b3ea818@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3714 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 14:45:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 14:45:21 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.bda4fccb511304d4734f6470d9348fbd@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.1 => 8.2.1-rc1 * milestone: 8.2.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 14:47:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 14:47:58 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.c28e62db4b166543fc017162432191a9@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately the STG lint issue is due to a bug in the linter. See #13941 and fix Phab:D3714. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 16:00:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 16:00:34 -0000 Subject: [GHC] #13815: Support Windows big-obj format In-Reply-To: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> References: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> Message-ID: <059.76916656b08be942706b464b8513aa02@haskell.org> #13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3523 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"81377e9e4bd52256946114d9c1dd966d5e3e7692/ghc" 81377e9e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="81377e9e4bd52256946114d9c1dd966d5e3e7692" Big-obj support for the Windows runtime linker Summary: The normal object file on Windows has a limit of `2^16` sections that can be in an object-file. The `big-obj` format raises this to `2^32` sections. The implementation is made difficult because we now need to support two header formats and two section formats that differ only by a single element size within each. The element that's different is in the middle of the structs and since the structs are used to map regions of memory directly, it means we need to know which struct it is when we do the mapping or pointer arithmetics. This is the final Object-Code format which Windows compilers can generate which we do not support yet in GHCI. All other major compilers on the platforms can produce it and all linkers consume it (bfd and lld). See http://tinyurl.com/bigobj This patch abstracts away retrieving the fields to functions which all take an struct which describes which object format is currently being parsed. These functions are always in-lined as they're small but would looks messy being copy-pasted everywhere. Test Plan: ./validate and new test `big-obj` ``` Tamar at Rage MINGW64 /r $ gcc -c -Wa,-mbig-obj foo.c -o foo.o Tamar at Rage MINGW64 /r $ objdump -h foo.o foo.o: file format pe-bigobj-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000010 0000000000000000 0000000000000000 00000128 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 0000000000000000 0000000000000000 00000000 2**4 ALLOC, LOAD, DATA 2 .bss 00000000 0000000000000000 0000000000000000 00000000 2**4 ALLOC 3 .xdata 00000008 0000000000000000 0000000000000000 00000138 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata 0000000c 0000000000000000 0000000000000000 00000140 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .rdata$zzz 00000030 0000000000000000 0000000000000000 0000014c 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA Tamar at Rage MINGW64 /r $ echo main | ~/ghc/inplace/bin/ghc-stage2.exe --interactive bar.hs foo.o GHCi, version 8.3.20170430: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( bar.hs, interpreted ) Ok, modules loaded: Main. *Main> 17 *Main> Leaving GHCi. ``` Reviewers: austin, bgamari, erikd, simonmar Subscribers: awson, rwbarton, thomie, #ghc_windows_task_force GHC Trac Issues: #13815 Differential Revision: https://phabricator.haskell.org/D3523 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 16:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 16:01:20 -0000 Subject: [GHC] #13815: Support Windows big-obj format In-Reply-To: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> References: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> Message-ID: <059.27fcf7a51dec053430284d12864b464a@haskell.org> #13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 16:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 16:02:23 -0000 Subject: [GHC] #13815: Support Windows big-obj format In-Reply-To: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> References: <044.c8775a5b1225332f13eba63fedba7fc8@haskell.org> Message-ID: <059.beb4f4bfb19af7e0319e0197991ee874@haskell.org> #13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 16:26:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 16:26:25 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.a4147eec003bb0c93b11ad3bbca50d0f@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 ak3n]: > Yep, I tried to run the whole test suite and it finished with 417 unexpected failures. Well, chances are that most of the tests were pretty-printing information incorrectly, so this perhaps isn't so surprising. Make sure to eyeball the new test results to confirm that they look correct, and if so, you can run `make accept TEST="Test1 Test2 ... TestN"` to have GHC accept the new results. (If you're not sure, feel free to consult.) > Also, should we change `pprParendType (VarT v) = ppr v` too? Because of `pprExp _ (VarE v) = pprName' Applied v`. Good question. For consistency, I think we probably should apply this change to `VarE` as well. That being said, I'm not sure if you can actually have a type-level variable that's syntactically infix, so I don't think you can actually observe this behavior in practice. For instance, I tried this: {{{ λ> $([d| type F ((**) :: * -> * -> *) x y = x ** y |] >>= stringE . pprint) :30:14: error: Unexpected type ‘((**) :: * -> * -> *)’ In the type declaration for ‘F’ A type declaration should have form type F a b c = ... }}} But in case this ever changes, it would be nice to have Template Haskell Just Work™, so I'd be fine with this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 17:28:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 17:28:37 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.a1bf36f73de73abb1facf6074770b69e@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #12045 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 18:09:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 18:09:22 -0000 Subject: [GHC] #13942: Pretty-printer butchers function arrow fixity on GHC HEAD Message-ID: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> #13942: Pretty-printer butchers function arrow fixity on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| f :: Either Int (Int -> Int) f = undefined |]) }}} Pretty-prints incorrectly on GHC HEAD: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170706: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(5,3)-(7,6): Splicing declarations [d| f_a1sG :: Either Int (Int -> Int) f_a1sG = undefined |] ======> f_a4bj :: Either Int Int -> Int f_a4bj = undefined }}} But not on GHC 8.2.1-rc3: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(5,3)-(7,6): Splicing declarations [d| f_a1su :: Either Int (Int -> Int) f_a1su = undefined |] ======> f_a4aV :: Either Int (Int -> Int) f_a4aV = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 20:55:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 20:55:13 -0000 Subject: [GHC] #13942: Pretty-printer butchers function arrow fixity on GHC HEAD In-Reply-To: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> References: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> Message-ID: <065.e28e141f21c413a928c0102d86d4c4b5@haskell.org> #13942: Pretty-printer butchers function arrow fixity on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: alanz (added) Comment: This regression was introduced in 3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e (`Remove HsContext from ppr_mono_ty, and remove ppParendHsType`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 21:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 21:03:09 -0000 Subject: [GHC] #13942: Pretty-printer butchers function arrow fixity on GHC HEAD In-Reply-To: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> References: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> Message-ID: <065.7b8259b26b29ad144e3b93c552d7aaa5@haskell.org> #13942: Pretty-printer butchers function arrow fixity on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 21:12:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 21:12:31 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.37e47423a249aa3af29619cf713eba7d@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D3717 Comment: Oh, sorry, I was unclear, there were 417 unexpected failures with bad `pprName` version. The variant with proper `pprName' Applied` is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 21:30:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 21:30:31 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 Message-ID: <048.054af5c39346b78fae836436fb73b68c@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- GHC-8.0.1 compile this module in less than one seconds on my machine. Both GHC-8.2rc2 and GHC-8.2rc3 eat all 8GB of memory and don't show any signs of stopping. -dshow-passes shows this: {{{ [1 of 1] Compiling Data.List.Unrolled ( unrolled.hs, unrolled.o ) *** Parser [Data.List.Unrolled]: !!! Parser [Data.List.Unrolled]: finished in 0.00 milliseconds, allocated 3.434 megabytes *** Renamer/typechecker [Data.List.Unrolled]: }}} and then nothing. Only memory consumption grows. Code: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} module Data.List.Unrolled where import GHC.TypeLits -- | Drop @n@ elements from a list class Drop (n :: Nat) where drop :: [a] -> [a] instance {-# OVERLAPPING #-} Drop 0 where drop xs = xs {-# INLINE drop #-} instance {-# OVERLAPPABLE #-} (Drop (n - 1)) => Drop n where drop [] = [] drop (_ : xs) = drop @(n - 1) xs {-# INLINE drop #-} -- | Take @n@ elements from a list class Take (n :: Nat) where take :: [a] -> [a] instance {-# OVERLAPPING #-} Take 0 where take _ = [] {-# INLINE take #-} instance {-# OVERLAPPABLE #-} (Take (n - 1)) => Take n where take [] = [] take (x : xs) = x : take @(n - 1) xs {-# INLINE take #-} -- | Split list at @n at -th element. splitAt :: forall (n :: Nat) a. (Take n, Drop n) => [a] -> ([a], [a]) splitAt xs = (take @n xs, drop @n xs) -- | Split list into chunks of the given length @c at . @n@ is length of the list. class ChunksOf (n :: Nat) (c :: Nat) where chunksOf :: [a] -> [[a]] instance {-# OVERLAPPING #-} ChunksOf 0 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf 0 c where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} ChunksOf n 0 where chunksOf _ = [] {-# INLINE chunksOf #-} instance {-# OVERLAPPABLE #-} (Take c, Drop c, ChunksOf (n - 1) c) => ChunksOf n c where chunksOf xs = let (l, r) = splitAt @c xs in l : chunksOf @(n - 1) @c r {-# INLINE chunksOf #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 21:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 21:33:22 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.c41829fb8fc05411a470ca9538cf7f47@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So to recap, `takeMVar` is getting passed a pointer that does not appear to point to an `MVar` closure. There are two reasons for this, 1. the closure was once an `MVar` but overwritten by someone since it was allocated (implying that whatever code overwrote the closure is at fault) 2. the pointer is invalid (implying that some parent in the callgraph may be at fault, or they took the pointer from another closure which itself was trampled on by someone else). I believe I've ruled out (1): watching the closure's memory suggests that there never was an `MVar` closure at this address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 8 22:06:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Jul 2017 22:06:05 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.e42a4b8951a5061d9e956eb7185ffca4@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed a `FUN` closure is being passed to `GHC.IO.Handle.hIsClosed`, which expects a `Handle`. `hIsClosed` then later calls `GHC.IO.Handle.Internals.do_operation`, which in turn calls `takeMVar`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 00:20:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 00:20:21 -0000 Subject: [GHC] #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail In-Reply-To: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> References: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> Message-ID: <062.2d849c021ea2ee1182c253313e444552@haskell.org> #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail -------------------------------------+------------------------------------- Reporter: mjvoge02 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: | Keywords: autoconf, | AC_CHECK_FUNC, configure, nixos Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mjvoge02): It did indeed fix it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 01:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 01:02:42 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.869c30a5a4903cb580ee8dc3eb054520@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 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 RyanGlScott): This behavior started with commit 748b79741652028827b6225c36b8ab55d22bdeb0 (`Use top-level instances to solve superclasses where possible`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 01:42:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 01:42:49 -0000 Subject: [GHC] #13944: Introduce synchronized FFI Message-ID: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some though i think we should Introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 01:47:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 01:47:47 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.e4f75ad01067cbbf23b2f07ab401acc3@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by winter: @@ -8,1 +8,1 @@ - After some though i think we should Introduce a new FFI type, let call it + After some thought i think we should introduce a new FFI type, let call it New description: During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some thought i think we should introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 02:00:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 02:00:00 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.dcd365d7d428e1835423eb26d57d0a8f@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by winter: @@ -20,0 +20,4 @@ + 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if + we can find a way to let it join parallel GC that would be better). + Otherwise it continue to work. + @@ -23,1 +27,2 @@ - anyway. + anyway, we can combine this with the new `-qn` RTS parameter: as long as + there're more than `n` threads can join GC, we do GC. New description: During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some thought i think we should introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if we can find a way to let it join parallel GC that would be better). Otherwise it continue to work. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway, we can combine this with the new `-qn` RTS parameter: as long as there're more than `n` threads can join GC, we do GC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 03:15:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 03:15:51 -0000 Subject: [GHC] #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail In-Reply-To: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> References: <047.23328fa33d81a28d77f03bcfcc2312f1@haskell.org> Message-ID: <062.61922cadb7cde27b703ebe3e1ba2c60b@haskell.org> #13935: AC_CHECK_FUNC yields incorrect result for pthread functions on NixOS causing build to fail -------------------------------------+------------------------------------- Reporter: mjvoge02 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: fixed | Keywords: autoconf, | AC_CHECK_FUNC, configure, nixos Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 07:11:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 07:11:56 -0000 Subject: [GHC] #13945: make install fails when registering packages Message-ID: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> #13945: make install fails when registering packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- In the final part of installation when packages are registered, the following command fails {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708" '' '/home/pgrads/mp16005/linux/installed-ghc' '/home/pgrads/mp16005/linux /installed-ghc/lib/ghc-8.2.0.20170708' '/home/pgrads/mp16005/linux /installed-ghc/share/doc/ghc-8.2.0.20170708/html/libraries' NO }}} with the following output {{{ Registering library for ghc-prim-0.5.0.0.. ghc-cabal: '/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg' exited with an error: ghc-pkg: Couldn't open database /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d for modification: {handle: /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) }}} It might be something to do with the permissions I have on my machine but I used to be able to install ghc if I gave it a suitable prefix other than `/usr/local`. Here is the call stack from the crash if that's useful. {{{ CallStack (from HasCallStack): die', called at libraries/Cabal/Cabal/Distribution/Simple/Program/Run.hs:142:7 in main:Distribution.Simple.Program.Run runProgramInvocation, called at libraries/Cabal/Cabal/Distribution/Simple/Program/HcPkg.hs:167:5 in main:Distribution.Simple.Program.HcPkg register, called at libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1709:5 in main:Distribution.Simple.GHC registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:350:14 in main:Distribution.Simple.Register registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:172:16 in main:Distribution.Simple.Register registerAll, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:125:5 in main:Distribution.Simple.Register register, called at libraries/Cabal/Cabal/Distribution/Simple.hs:770:10 in main:Distribution.Simple defaultRegHook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:584:20 in main:Distribution.Simple regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:452:38 in main:Distribution.Simple cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:469:4 in main:Distribution.Simple hookedActionWithArgs, called at libraries/Cabal/Cabal/Distribution/Simple.hs:451:5 in main:Distribution.Simple hookedAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:430:5 in main:Distribution.Simple registerAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:184:50 in main:Distribution.Simple defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:133:28 in main:Distribution.Simple defaultMainWithHooksArgs, called at utils/ghc-cabal/Main.hs:214:6 in main:Main }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 08:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 08:54:03 -0000 Subject: =?utf-8?b?W0dIQ10gIzEzOTQ2OiDoh6rli5Xpgbjmk4flr6bkvos=?= Message-ID: <044.8216c8284ee6a7369c87721ade5314ce@haskell.org> #13946: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} class B a b where b :: a -> b instance B Int Char where b = error "B Int Char" instance B Int () where b = error "B Int ()" }}} {{{ *Main> :t (b undefined)::Char :1:2: error: • Ambiguous type variable ‘a0’ arising from a use of ‘b’ prevents the constraint ‘(B a0 Char)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instance exist: instance [safe] B Int Char -- Defined at t.hs:6:10 • In the expression: (b undefined) :: Char }}} 怎麼讓GHC在這種情況下自動選擇任意一個實例 [WARING]Google Translate How to make GHC automatically select any instance in this case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 08:54:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 08:54:33 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzk0Njog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.8216c8284ee6a7369c87721ade5314ce@haskell.org> References: <044.8216c8284ee6a7369c87721ade5314ce@haskell.org> Message-ID: <059.00082b7bcc144a356fbeda0f3cb89199@haskell.org> #13946: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Description changed by zaoqi: @@ -28,0 +28,1 @@ + New description: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} class B a b where b :: a -> b instance B Int Char where b = error "B Int Char" instance B Int () where b = error "B Int ()" }}} {{{ *Main> :t (b undefined)::Char :1:2: error: • Ambiguous type variable ‘a0’ arising from a use of ‘b’ prevents the constraint ‘(B a0 Char)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instance exist: instance [safe] B Int Char -- Defined at t.hs:6:10 • In the expression: (b undefined) :: Char }}} 怎麼讓GHC在這種情況下自動選擇任意一個實例 [WARING]Google Translate How to make GHC automatically select any instance in this case -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 11:33:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 11:33:26 -0000 Subject: [GHC] #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation (was: Segfault in Windows GHCi involving C code compiled with -O4) In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.d6db61f20c60fbc470b1556ceb06be17@haskell.org> #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * related: => #7134 Comment: So I've finally had some time to track this one down. The difference between the `-O2` and the `-O3` code is that the `-O3` code is vectorized and the constants are moved to `.rdata`. To get to the constants a `R_X86_64_PC32` relocation is used. {{{ ac: 48 c1 e0 02 shl $0x2,%rax b0: 31 db xor %ebx,%ebx b2: 66 0f 6f 15 00 00 00 movdqa 0x0(%rip),%xmm2 # ba b9: 00 b6: R_X86_64_PC32 .rdata ba: 48 8d 2c 02 lea (%rdx,%rax,1),%rbp be: 41 c1 ea 02 shr $0x2,%r10d }}} At runtime the program segfaults at `0xb2` when attempting to read from `.rdata`. {{{ │0xced01d2 shl $0x2,%rax │ │0xced01d6 xor %ebx,%ebx │ >│0xced01d8 movdqa 0xd8(%rip),%xmm2 # 0xced02b8 │ │0xced01e0 lea (%rdx,%rax,1),%rbp │ │0xced01e4 shr $0x2,%r10d }}} The calculated address for `.rdata` is correct, `0xced02b8`: {{{ (gdb) x/10i 0xced02b8 0xced02b8: add %eax,(%rax) 0xced02ba: add %al,(%rax) 0xced02bc: add %eax,(%rax) 0xced02be: add %al,(%rax) 0xced02c0: add %eax,(%rax) 0xced02c2: add %al,(%rax) 0xced02c4: add %eax,(%rax) 0xced02c6: add %al,(%rax) 0xced02c8: rex.RXB 0xced02c9: rex.XB }}} and the object file has {{{ Disassembly of section .rdata: 0000000000000000 <.rdata>: 0: 01 00 add %eax,(%rax) 2: 00 00 add %al,(%rax) 4: 01 00 add %eax,(%rax) 6: 00 00 add %al,(%rax) 8: 01 00 add %eax,(%rax) a: 00 00 add %al,(%rax) c: 01 00 add %eax,(%rax) ... }}} However the code is referencing this address. So I suspect it's expecting a trampoline here. So perhaps `R_X86_64_PC32` should be allocated using a jump island. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 11:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 11:52:18 -0000 Subject: [GHC] #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.5d571066a37946d4791150f04b1f4f16@haskell.org> #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): It seems the code for `R_X86_64_PC32` does already make a trampoline, but only when the address is more than `32-bits` away: {{{ case 4: /* R_X86_64_PC32 (ELF constant 2) - IMAGE_REL_AMD64_REL32 (PE constant 4) */ { intptr_t v; v = ((intptr_t)S) + ((intptr_t)(int32_t)A) - ((intptr_t)pP) - 4; if ((v >> 32) && ((-v) >> 32)) { /* Make the trampoline then */ copyName ( getSymShortName (info, sym), strtab, symbol, 1000-1 ); S = makeSymbolExtra_PEi386(oc, symIndex, S, (char *)symbol); /* And retry */ v = ((intptr_t)S) + ((intptr_t)(int32_t)A) - ((intptr_t)pP) - 4; if ((v >> 32) && ((-v) >> 32)) { barf("IMAGE_REL_AMD64_REL32: High bits are set in %zx for %s", v, (char *)symbol); } } *(uint32_t *)pP = (uint32_t)v; break; } }}} Which explains why it doesn't always segfault.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 11:53:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 11:53:00 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.a1c29c138c6d4dd491c20fb34755409f@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://www.youtube.com/watch?v=5Py0l7CfQTo&index=24&list=PLMTm6Ln7vQZZv6sQ0I4R7iaIjvSVhHXod#t=69.164308 Daniel Patterson - FunTAL: Reasonably Mixing a Functional Language with Assembly] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 13:50:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 13:50:26 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.d29de3e026ac6d166bc74708b5bee0f1@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): I don't see how this could work (or I've misunderstood your proposal). Consider that you have a thread with some reference to some heap object (call it `A`) sitting in another capability's nursery. Let's say that it enters a `synchronized` call and while the call is running a GC is started. During this GC another other capability evacuates `A` (producing a new object, say `A'`) and the nursery in which it lived is freed. Now we have a situation where the thread who made the call has a reference to `A`, an object which existed in a no-longer-existing heap block, which it may attempt to dereference once the call completes. The distinguishing feature of the `safe` call mechanism is that we suspend the running thread, saving all of its state back to its TSO, where they can be handled by the garbage collector. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 14:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 14:50:44 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.08c4df089ec464d287daa5979fa834b8@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): I'm not even sure that my proposal work :) but let's try to have a discussion on this idea. Remember the new `-qn` RTS flag, which allow some inactive threads doesn't participate GC, (The word participate seems too vague, i think it means the thread doesn't do GC work, but do get GCed by other GC worker thread). Now a thread which enter `synchronized` call will behave exactly like an inactive thread which is not selected to do GC work, that means its root will get GCed by some other thread, which is OK since `synchronized` FFI restrict what kind of heap object it can reference. I'm not totally clear how this idea works because i'm not an expert on RTS, all clarifications and suggestions are welcomed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 16:00:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 16:00:22 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.55550246fcc595a10f15d31bead10d03@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: I can't tell what your problem is from just a single code snippet. We're not mind-readers - please explain clearly what the issue is! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 16:05:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 16:05:20 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzk0Njog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.8216c8284ee6a7369c87721ade5314ce@haskell.org> References: <044.8216c8284ee6a7369c87721ade5314ce@haskell.org> Message-ID: <059.984444df712f566931f6bbcc52799616@haskell.org> #13946: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: This is behaving as expected. The issue is that when you type `(b undefined) :: Char`, GHC attempts to look for a `B a Char` instance. But `a` is underdetermined, so GHC cannot successfully find an instance. What you //can// do is use `FunctionalDependencies` to inform GHC that `b` uniquely determines `a`. That is, you can do this: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} class B a b | b -> a where b :: a -> b instance B Int Char where b = error "B Int Char" instance B Int () where b = error "B Int ()" }}} Note the use of `| b -> a` in the class declaration for `B`. This is the notation used to express that `b` uniquely determines `a`. Now, if you try this: {{{#!hs > :t (b undefined) :: Char (b undefined) :: Char :: Char }}} It works, since when GHC tries to find a `B a Char` instance, it knows that `Char` uniquely determines what `a` should be (in this case, `Int`), so it finds the `B Int Char` and proceeds. I'm going to close this as invalid - please reopen if this didn't answer your question in a satisfactory way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 17:16:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 17:16:13 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor Message-ID: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where f :: () -> Int :~: Int f = undefined }}} GHC 8.0.2 gives a reasonable error message: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ }}} But GHC 8.2.1's error message is much more confusing: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:6: error: Precedence parsing error cannot mix ‘(->)’ [infixr 0] and ‘:~:’ [infixl 0] in the same infix expression | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^^^^^^^ Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ A data constructor of that name is in scope; did you mean DataKinds? | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^ }}} I was thrown akilter by the claim that `:~:` was `infixl 0`, since it was displayed before the real cause of the error (that it's out-of-scope). Adding `import Data.Type.Equality` fixes the error, but GHC really shouldn't be making claims about the fixities of out-of-scope type constructors in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 19:00:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 19:00:02 -0000 Subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi (was: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation) In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.19fdb9ecb01c3a5b2babb1e276b7c521@haskell.org> #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): My initial analysis was wrong, the code isn't expecting a trampoline, it's data not code. It's simply trying to load the loop iteration increment into the SSE registers. {{{ (gdb) x/10x 0xced02b8 0xced02b8: 0x00000001 0x00000001 0x00000001 0x00000001 0xced02c8: 0x3a434347 0x65522820 0x202c3276 0x6c697542 0xced02d8: 0x79622074 0x59534d20 }}} The loop seems to have undergone 4-way vectorization. I'm not certain why this is failing.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 19:02:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 19:02:58 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.16951c5e9cdb6e57ce57d5a702bf5244@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: adamgundry (added) Comment: This started occurring in commit 2484d4dae65c81f218dcfe494b963b2630bb8fa6 (`Refactor renaming of operators/sections to fix DuplicateRecordFields bugs`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 20:02:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 20:02:57 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.fed1477fd12b5019cc8832ce88705607@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 20:03:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 20:03:13 -0000 Subject: [GHC] #13847: record construction accepts local unqualified name instead of qualified imported name In-Reply-To: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> References: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> Message-ID: <064.896efbc7a9064650088d5d1a8067355a@haskell.org> #13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 20:13:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 20:13:06 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.18f16442d87f4fcbd162f01c64d3216d@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: (none) => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 20:26:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 20:26:43 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.0a5d53e50c0060be468bbebdf4b4551b@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott Comment: After skimming the commitdiff, I'm reasonably confident I know what is happening, and how fix it. I'll post a Phab Diff after I've validated. Also, I just realized that there's another problem with the error message in GHC 8.2: it claims that a constructor `:~:` is in scope, but that's untrue. I'll submit a separate ticket for this later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 22:04:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 22:04:12 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.c5ddd43d36f4795a4bf7697e2c926a18@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3718 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3718 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 22:12:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 22:12:57 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error (was: make install fails when registering packages) In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.0419cacedd44fcd5be29fa3244f1c1fc@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: goldfire (added) @@ -35,1 +35,3 @@ - Here is the call stack from the crash if that's useful. + A workaround is to make sure that `HAVE_FLOCK` is not defined, the way I + did this was commenting out the three relevant lines in + libraries/base/configure.ac. @@ -37,50 +39,7 @@ - {{{ - CallStack (from HasCallStack): - die', called at - libraries/Cabal/Cabal/Distribution/Simple/Program/Run.hs:142:7 in - main:Distribution.Simple.Program.Run - runProgramInvocation, called at - libraries/Cabal/Cabal/Distribution/Simple/Program/HcPkg.hs:167:5 in - main:Distribution.Simple.Program.HcPkg - register, called at - libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1709:5 in - main:Distribution.Simple.GHC - registerPackage, called at - libraries/Cabal/Cabal/Distribution/Simple/Register.hs:350:14 in - main:Distribution.Simple.Register - registerPackage, called at - libraries/Cabal/Cabal/Distribution/Simple/Register.hs:172:16 in - main:Distribution.Simple.Register - registerAll, called at - libraries/Cabal/Cabal/Distribution/Simple/Register.hs:125:5 in - main:Distribution.Simple.Register - register, called at libraries/Cabal/Cabal/Distribution/Simple.hs:770:10 - in main:Distribution.Simple - defaultRegHook, called at - libraries/Cabal/Cabal/Distribution/Simple.hs:584:20 in - main:Distribution.Simple - regHook, called at - libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in - main:Distribution.Simple.UserHooks - regHook, called at - libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in - main:Distribution.Simple.UserHooks - cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:452:38 - in main:Distribution.Simple - cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:469:4 - in main:Distribution.Simple - hookedActionWithArgs, called at - libraries/Cabal/Cabal/Distribution/Simple.hs:451:5 in - main:Distribution.Simple - hookedAction, called at - libraries/Cabal/Cabal/Distribution/Simple.hs:430:5 in - main:Distribution.Simple - registerAction, called at - libraries/Cabal/Cabal/Distribution/Simple.hs:184:50 in - main:Distribution.Simple - defaultMainHelper, called at - libraries/Cabal/Cabal/Distribution/Simple.hs:133:28 in - main:Distribution.Simple - defaultMainWithHooksArgs, called at utils/ghc-cabal/Main.hs:214:6 in - main:Main - }}} + geekosaur suggests on IRC that the problem might be + + > what might be possible is that hLock uses fcntl locking, ghc-pkg opens a + database r/o if it can't open it > r/w, and it tried to acquire a write + lock (which will fail with EBADF if the file descriptor is only open for > + > read). and there is an SElinux context prohibiting your process opening + the db for write New description: In the final part of installation when packages are registered, the following command fails {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708" '' '/home/pgrads/mp16005/linux/installed-ghc' '/home/pgrads/mp16005/linux /installed-ghc/lib/ghc-8.2.0.20170708' '/home/pgrads/mp16005/linux /installed-ghc/share/doc/ghc-8.2.0.20170708/html/libraries' NO }}} with the following output {{{ Registering library for ghc-prim-0.5.0.0.. ghc-cabal: '/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg' exited with an error: ghc-pkg: Couldn't open database /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d for modification: {handle: /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) }}} It might be something to do with the permissions I have on my machine but I used to be able to install ghc if I gave it a suitable prefix other than `/usr/local`. A workaround is to make sure that `HAVE_FLOCK` is not defined, the way I did this was commenting out the three relevant lines in libraries/base/configure.ac. geekosaur suggests on IRC that the problem might be > what might be possible is that hLock uses fcntl locking, ghc-pkg opens a database r/o if it can't open it > r/w, and it tried to acquire a write lock (which will fail with EBADF if the file descriptor is only open for > > read). and there is an SElinux context prohibiting your process opening the db for write -- Comment: I updated the ticket as I think this will be a more general problem using 8.2.1 on any system where these restrictions exist. I can't properly diagnose the problem but geekosaur speculates an explanation which seemed plausible. This also seems the same issue that Richard was having back in March. https://mail.haskell.org/pipermail/ghc-devs/2017-March/013915.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 22:40:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 22:40:37 -0000 Subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.75172697ee40df0a86655a1b2aa528e9@haskell.org> #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by olsner): I think the issue is alignment - `movdqa` requires 16-byte alignment and the data here seems to start at `0x...8` which is only 8-byte aligned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 23:13:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 23:13:14 -0000 Subject: [GHC] #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 Message-ID: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #13568 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (the fix for #13568), which debuted in GHC 8.2, GHC thinks that out-of-scope identifiers are actually in-scope! {{{#!hs module Bug where f :: T f = undefined }}} In GHC 8.2.1-rc3, the error message is: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:6: error: Not in scope: type constructor or class ‘T’ A data constructor of that name is in scope; did you mean DataKinds? | 3 | f :: T | ^ }}} Compare this to GHC 8.0.2, which gives a more sensible error message: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:6: error: Not in scope: type constructor or class ‘T’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 23:13:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 23:13:45 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.02f553c50bbb28fc30acb3dd9e510a6d@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3718 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've opened #13948 for the `A data constructor of that name is in scope` issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 23:18:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 23:18:06 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell Message-ID: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Reported by leftaroundabout at [https://github.com/haskell/haddock/issues/650]. Surely this is a bug in GhcMake.enableCodegenForTH introduced in 53c78be0aab76a3107c4dacbb1d177afacdd37fa. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 9 23:18:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Jul 2017 23:18:13 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.af9de31594b413a675634fe7433ec00b@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Changes (by duog): * owner: (none) => duog -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 00:11:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 00:11:19 -0000 Subject: [GHC] #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 In-Reply-To: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> References: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> Message-ID: <065.74ccf4b36c8b1d80530a648a54e742df@haskell.org> #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13568 | Differential Rev(s): Phab:D3719 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3719 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 00:17:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 00:17:14 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.6356bd5b7e6ccbb4424acc7ca26bdc4d@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: | -------------------------------------+------------------------------------- Changes (by duog): * cc: alexbiehl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 00:51:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 00:51:05 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.5af32f89c5e5e712d289030253a7f290@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3720 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => Phab:D3720 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 02:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 02:06:11 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.7ee75ab1954530296e05f011163132f4@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): OK, now i'm pretty sure what `synchronized` would do, it will behave just like a `safe` FFI call with one difference: a task which comes across a `synchronized` call will give off its capacity, but will not hand off it to other tasks unless that's a GC task. This means `synchronized` calls will still block whole capacity, but it will not spawn new threads, nor blocking GC. I'm not sure if this make sense, it seems the overhead of safe FFI calls come from both the capacity transfer and creating new OS threads. But i'm not sure which is more costly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 03:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 03:06:27 -0000 Subject: [GHC] #13950: IncoherentInstances Message-ID: <044.f9a09288f54e1d744259c88e2c12fb39@haskell.org> #13950: IncoherentInstances -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple IncoherentInstances | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, NoMonomorphismRestriction #-} module Data.U where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class Usuccs a b where usuccs :: U a -> U b instance Usuccs a a where usuccs = id instance Usuccs xs ys => Usuccs xs (y : ys) where usuccs xs = USucc (usuccs xs) u x = usuccs (UOne x) }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load U.hs [1 of 1] Compiling Data.U ( U.hs, interpreted ) Ok, modules loaded: Data.U. *Data.U> :set -XDataKinds *Data.U> (u 'c')::U [String, Char, Int] :3:2: error: • Overlapping instances for Usuccs (Char : xs0) '[Char, Int] arising from a use of ‘u’ Matching instances: instance [safe] Usuccs a a -- Defined at U.hs:25:10 ...plus one instance involving out-of-scope types (use -fprint-potential-instances to see them all) (The choice depends on the instantiation of ‘xs0’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) • In the expression: (u 'c') :: U '[String, Char, Int] In an equation for ‘it’: it = (u 'c') :: U '[String, Char, Int] }}} {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction #-} module Data.U where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class Usuccs a b where usuccs :: U a -> U b instance Usuccs a a where usuccs = id instance Usuccs xs ys => Usuccs xs (y : ys) where usuccs xs = USucc (usuccs xs) u x = usuccs (UOne x) }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load U.hs [1 of 1] Compiling Data.U ( U.hs, interpreted ) Ok, modules loaded: Data.U. *Data.U> :set -XDataKinds *Data.U> (u 'c')::U [String, Char, Int] :3:2: error: • No instance for (Usuccs (Char : xs0) '[]) arising from a use of ‘u’ • In the expression: (u 'c') :: U '[String, Char, Int] In an equation for ‘it’: it = (u 'c') :: U '[String, Char, Int] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 04:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 04:26:12 -0000 Subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.f56f86e3b2b1111f304ec11ac4cc7494@haskell.org> #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): Ack, how did I miss the alignment note on the manual.. You're right, and the section is supposed to be 16-byte aligned {{{ 6 .rdata 00000010 0000000000000000 0000000000000000 000002ec 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA }}} Simple enough fix. Thanks @olsner, completely read over that a few times.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 04:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 04:26:41 -0000 Subject: [GHC] #13617: GHCi linker does not honor alignment of sections. (was: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi) In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.3fa4bce19e31ab7db9732b15bc97a299@haskell.org> #13617: GHCi linker does not honor alignment of sections. --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 04:29:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 04:29:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.3d4c8e736594c2593e1aa31f04c48081@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 zaoqi): Replying to [comment:4 RyanGlScott]: > I can't tell what your problem is from just a single code snippet. We're not mind-readers - please explain clearly what the issue is! #13950 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 05:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 05:23:13 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.7d48b90975b15a574907b0dbfa387722@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: upstream Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 05:25:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 05:25:41 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.cfe77c5b42d60675fcda4de519a2a538@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: upstream => patch * differential: => Phab:D3723 Comment: I've submitted Phab:D3723 to remove `bitSize`. My only question is whether we should add it back as a function {{{#!hs bitSize :: FiniteBitSize a => a -> Int bitSize = finiteBitSize }}} to reduce unnecessary breakage. This only goes so far; module import lines may need to be changed to fix old code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 06:42:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 06:42:53 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.cfa3cdd9f42af451fcb71232249543f7@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:7 dfeuer]: > I've submitted Phab:D3723 to remove `bitSize`. My only question is whether we should add it back as a function to be fair, bitSize was deprecated 3 years ago in GHC 7.8; and when GHC 8.4 is released that'll be 4 years. If the point of a deprecation is to eventually rid the API of the deprecated entity, 4 years (or a 4 rls window) is IMO more than enough time for everyone to adapt... ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 06:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 06:50:44 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.b040a1b7e8b04ac8206394d13afd535c@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 hvr]: > Replying to [comment:7 dfeuer]: > > I've submitted Phab:D3723 to remove `bitSize`. My only question is whether we should add it back as a function > > to be fair, bitSize was deprecated 3 years ago in GHC 7.8; and when GHC 8.4 is released that'll be 4 years. If the point of a deprecation is to eventually rid the API of the deprecated entity, 4 years (or a 4 rls window) is IMO more than enough time for everyone to adapt... ;-) For sure. It's a bit sad, though, that we're discarding a perfectly good name simply because it was originally stuck in the wrong class. I guess that's life. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 06:54:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 06:54:48 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.6ec7de061f0ef72c234a5390104ee54b@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): > For sure. It's a bit sad, though, that we're discarding a perfectly good name simply because it was originally stuck in the wrong class. I guess that's life. Oh, now that I read the type-sig more carefully, I see it changes from `BitSize a =>` to `FiniteBitSize a =>`; which makes me more neutral on this. I guess it's a sensible thing to do; the only downside is that we carry around redundancy (e.g. an alias for `finiteBiteSize`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 11:04:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 11:04:14 -0000 Subject: [GHC] #13942: Pretty-printer butchers function arrow fixity on GHC HEAD In-Reply-To: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> References: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> Message-ID: <065.fbbb912e7af8b81e9153a116ba5f4d0b@haskell.org> #13942: Pretty-printer butchers function arrow fixity on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"c506f8353755333e21d5ee35bc71d2c8f9ddcb1b/ghc" c506f835/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c506f8353755333e21d5ee35bc71d2c8f9ddcb1b" Pretty-printer no longer butchers function arrow fixity It now correctly prints the parens around '(Int -> Int)' in {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| f :: Either Int (Int -> Int) f = undefined |]) Closes #13942 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 11:06:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 11:06:26 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.961e3d65b2004fcbf9999df32fe32e3e@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * version: 8.0.1 => 8.2.1-rc3 Comment: I confirmed this happens with the `ghc-8.2.1-rc3` bindist as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 12:25:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 12:25:49 -0000 Subject: [GHC] #13950: IncoherentInstances In-Reply-To: <044.f9a09288f54e1d744259c88e2c12fb39@haskell.org> References: <044.f9a09288f54e1d744259c88e2c12fb39@haskell.org> Message-ID: <059.aff877e24c7f194a6e6efd325556ed4f@haskell.org> #13950: IncoherentInstances -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | IncoherentInstances 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 hsyl20): {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction #-} {-# LANGUAGE ScopedTypeVariables #-} module Data.U where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class Usuccs a b where usuccs :: U a -> U b instance Usuccs a a where usuccs = id instance Usuccs xs ys => Usuccs (x : xs) (x : ys) where usuccs (UOne x) = UOne x usuccs (USucc xs) = USucc (usuccs xs) instance Usuccs xs (x : xs) where usuccs = USucc instance Usuccs xs ys => Usuccs xs (y : ys) where usuccs x = USucc (usuccs x) instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs u :: forall t x. Usuccs '[x] t => x -> U t u x = usuccs (UOne x :: U '[x]) }}} {{{#!bash > :set -XDataKinds > (u 'c')::U [String, Char, Int] (u 'c') }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 12:36:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 12:36:48 -0000 Subject: [GHC] #13951: InScope set assertion failure from monad-skeleton Message-ID: <049.5db03d032e7f17d002eb17274d5a81f3@haskell.org> #13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE PolyKinds, GADTs, Rank2Types, ScopedTypeVariables, Trustworthy #-} module Control.Monad.Skeleton.Internal where data Cat k a b where Empty :: Cat k a a Leaf :: k a b -> Cat k a b Tree :: Cat k a b -> Cat k b c -> Cat k a c viewL :: forall k a b r. Cat k a b -> ((a ~ b) => r) -> (forall x. k a x -> Cat k x b -> r) -> r viewL Empty e _ = e viewL (Leaf k) _ r = k `r` Empty viewL (Tree a b) e r = go a b where go :: Cat k a x -> Cat k x b -> r go Empty t = viewL t e r go (Leaf k) t = r k t go (Tree c d) t = go c (Tree d t) }}} Leads to the assertion failure {{{ [1 of 1] Compiling Control.Monad.Skeleton.Internal ( Internal.hs, Internal.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 2160 Just 3 [] ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170708 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {x_avF ds_d14c} tenv [avF :-> x_avF] tenvFVs [avF :-> x_avF, a11Z :-> k_a11Z] cenv [] cenvFVs [] tys [k1_a120 a_a121 x_avF] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 13:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 13:21:28 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.0ec5d66af55c8a4a612ad394a34ab7be@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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 mpickering): With a `NO_FLOCK` build, I have to compile package with cabal with `-j1` otherwise very strange errors happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 13:46:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 13:46:09 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.c137f9b84b105420ea2075a3807ebb5b@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 13:47:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 13:47:18 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.87251c0e77714e73a528f5826f5b5262@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by bgamari: @@ -42,4 +42,4 @@ - database r/o if it can't open it > r/w, and it tried to acquire a write - lock (which will fail with EBADF if the file descriptor is only open for > - > read). and there is an SElinux context prohibiting your process opening - the db for write + database r/o if it can't open it r/w, and it tried to acquire a write lock + (which will fail with EBADF if the file descriptor is only open for read). + and there is an SElinux context prohibiting your process opening the db + for write New description: In the final part of installation when packages are registered, the following command fails {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708" '' '/home/pgrads/mp16005/linux/installed-ghc' '/home/pgrads/mp16005/linux /installed-ghc/lib/ghc-8.2.0.20170708' '/home/pgrads/mp16005/linux /installed-ghc/share/doc/ghc-8.2.0.20170708/html/libraries' NO }}} with the following output {{{ Registering library for ghc-prim-0.5.0.0.. ghc-cabal: '/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg' exited with an error: ghc-pkg: Couldn't open database /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d for modification: {handle: /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) }}} It might be something to do with the permissions I have on my machine but I used to be able to install ghc if I gave it a suitable prefix other than `/usr/local`. A workaround is to make sure that `HAVE_FLOCK` is not defined, the way I did this was commenting out the three relevant lines in libraries/base/configure.ac. geekosaur suggests on IRC that the problem might be > what might be possible is that hLock uses fcntl locking, ghc-pkg opens a database r/o if it can't open it r/w, and it tried to acquire a write lock (which will fail with EBADF if the file descriptor is only open for read). and there is an SElinux context prohibiting your process opening the db for write -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 14:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 14:04:10 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.08997d0b764386433a39a311f8bb3bb5@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): mpickering is using CentOS (which indeed uses SELinux, IIRC). goldfire, are you as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 14:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 14:20:48 -0000 Subject: [GHC] #13952: Liberal coverage condition fails if TypeInType is enabled Message-ID: <049.2413136f29a872593d3df719b6ba430c@haskell.org> #13952: Liberal coverage condition fails if TypeInType is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 program compiles with 8.0.2 but fails with 8.2.1-rc2. It succeeds if the `TypeInType` extension is disabled. {{{#!hs {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE DataKinds, FlexibleContexts, FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses, TypeFamilies, TypeOperators #-} -- Removing TypeInType causes compilation to succeed {-# LANGUAGE TypeInType #-} module Bookkeeper.Internal where import GHC.Generics import GHC.TypeLits (Symbol, KnownSymbol, TypeError, ErrorMessage(..)) class FromGeneric a book | a -> book where fromGeneric :: a x -> book type family Expected a where Expected (l :+: r) = TypeError ('Text "Cannot convert sum types into Books") Expected U1 = TypeError ('Text "Cannot convert non-record types into Books") instance (book ~ Expected U1) => FromGeneric U1 book where fromGeneric = error "impossible" }}} {{{ src/Bookkeeper/Internal.hs:18:10: error: • Illegal instance declaration for ‘FromGeneric U1 book’ The coverage condition fails in class ‘FromGeneric’ for functional dependency: ‘a -> book’ Reason: lhs type ‘U1’ does not determine rhs type ‘book’ Un-determined variable: book • In the instance declaration for ‘FromGeneric U1 book’ | 18 | instance (book ~ Expected U1) => FromGeneric U1 book where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Perhaps this is related to #12803 but I made another ticket so that it can be diagnosed separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 14:35:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 14:35:44 -0000 Subject: [GHC] #13953: forall Message-ID: <044.aac045209afeb03cdfc3af409d3c8450@haskell.org> #13953: forall -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: forall | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction, ScopedTypeVariables #-} module Data.U where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class Usuccs a b where usuccs :: U a -> U b instance Usuccs a a where usuccs = id instance Usuccs xs ys => Usuccs (x : xs) (x : ys) where usuccs (UOne x) = UOne x usuccs (USucc xs) = USucc (usuccs xs) instance Usuccs xs (x : xs) where usuccs = USucc instance Usuccs xs ys => Usuccs xs (y : ys) where usuccs x = USucc (usuccs x) u :: forall x xs. Usuccs '[x] xs => x -> U xs u x = usuccs (UOne x :: U '[x]) class T a b where t :: U a -> U b instance Usuccs '[x] t => T '[x] t where t (UOne x) = u x instance (T xs t, Usuccs '[x] t) => T (x ': xs) t where t (UOne x) = u x t (USucc xs) = t xs instance Eq x => Eq (U '[x]) where UOne x == UOne y = x == y instance (Eq x, Eq (U xs)) => Eq (U (x : xs)) where UOne x == UOne y = x == y USucc xs == USucc ys = xs == ys _ == _ = False instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load U.hs [1 of 1] Compiling Data.U ( U.hs, interpreted ) Ok, modules loaded: Data.U. *Data.U> :t u u :: Usuccs '[x] xs => x -> U xs }}} ------------------------------------------------------ {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, GADTs, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances, IncoherentInstances, NoMonomorphismRestriction, ScopedTypeVariables #-} module Data.U where data U :: [*] -> * where UOne :: x -> U (x : xs) USucc :: U xs -> U (x : xs) class Usuccs a b where usuccs :: U a -> U b instance Usuccs a a where usuccs = id instance Usuccs xs ys => Usuccs (x : xs) (x : ys) where usuccs (UOne x) = UOne x usuccs (USucc xs) = USucc (usuccs xs) instance Usuccs xs (x : xs) where usuccs = USucc instance Usuccs xs ys => Usuccs xs (y : ys) where usuccs x = USucc (usuccs x) u :: Usuccs '[x] xs => x -> U xs u x = usuccs (UOne x :: U '[x]) class T a b where t :: U a -> U b instance Usuccs '[x] t => T '[x] t where t (UOne x) = u x instance (T xs t, Usuccs '[x] t) => T (x ': xs) t where t (UOne x) = u x t (USucc xs) = t xs instance Eq x => Eq (U '[x]) where UOne x == UOne y = x == y instance (Eq x, Eq (U xs)) => Eq (U (x : xs)) where UOne x == UOne y = x == y USucc xs == USucc ys = xs == ys _ == _ = False instance Show x => Show (U '[x]) where show (UOne x) = "(u " ++ showsPrec 11 x ")" instance (Show x, Show (U xs)) => Show (U (x : xs)) where show (UOne x) = "(u " ++ showsPrec 11 x ")" show (USucc xs) = show xs }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load U.hs [1 of 1] Compiling Data.U ( U.hs, interpreted ) U.hs:39:7: error: • Could not deduce (Usuccs '[x0] xs) arising from a use of ‘usuccs’ from the context: Usuccs '[x] xs bound by the type signature for: u :: Usuccs '[x] xs => x -> U xs at U.hs:38:1-32 The type variable ‘x0’ is ambiguous Relevant bindings include u :: x -> U xs (bound at U.hs:39:1) • In the expression: usuccs (UOne x :: U '[x]) In an equation for ‘u’: u x = usuccs (UOne x :: U '[x]) U.hs:39:15: error: • Couldn't match type ‘x’ with ‘x1’ ‘x’ is a rigid type variable bound by the type signature for: u :: forall x (xs :: [*]). Usuccs '[x] xs => x -> U xs at U.hs:38:6 ‘x1’ is a rigid type variable bound by an expression type signature: forall x1. U '[x1] at U.hs:39:25 Expected type: U '[x1] Actual type: U '[x] • In the first argument of ‘usuccs’, namely ‘(UOne x :: U '[x])’ In the expression: usuccs (UOne x :: U '[x]) In an equation for ‘u’: u x = usuccs (UOne x :: U '[x]) • Relevant bindings include x :: x (bound at U.hs:39:3) u :: x -> U xs (bound at U.hs:39:1) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 14:36:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 14:36:10 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.337b707a748e6a87bb92aa2b54677ff4@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:13:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:13:30 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.09360bce8bcaa68b6eed00c736a953e9@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.2.2 Comment: Indeed the `Handle` argument passed to `killer` lambda is also a cons cell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:15:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:15:16 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.f4a80b449c93bab593161267d526238e@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmct): * cc: jmct (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:24:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:24:07 -0000 Subject: [GHC] #13942: Pretty-printer butchers function arrow fixity on GHC HEAD In-Reply-To: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> References: <050.3725846b91918d38d68623e7ddb913e2@haskell.org> Message-ID: <065.55aa7f1098f2022ae8dbad183b2ebd34@haskell.org> #13942: Pretty-printer butchers function arrow fixity on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:30:41 -0000 Subject: [GHC] #13953: forall In-Reply-To: <044.aac045209afeb03cdfc3af409d3c8450@haskell.org> References: <044.aac045209afeb03cdfc3af409d3c8450@haskell.org> Message-ID: <059.38fae4a02b5b328fee1bf2215171b3b5@haskell.org> #13953: forall -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: forall Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: This is completely expected behavior. To recap, the difference between your two programs is that the former program has this: {{{#!hs u :: forall x xs. Usuccs '[x] xs => x -> U xs u x = usuccs (UOne x :: U '[x]) }}} Which typechecks. The latter program: {{{#!hs u :: Usuccs '[x] xs => x -> U xs u x = usuccs (UOne x :: U '[x]) }}} Which lacks an explicit `forall`, does not typecheck. The reason is because by default, the type variables in a function's type signature do not scope over the function body. To enable this behavior, you have to turn on `ScopedTypeVariables` and quantify the type variables explicitly with a `forall`. Refer to [https://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html?highlight=scopedtypevariables #decl-type-sigs this section] of the users' guide for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:37:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:37:17 -0000 Subject: [GHC] #13950: IncoherentInstances In-Reply-To: <044.f9a09288f54e1d744259c88e2c12fb39@haskell.org> References: <044.f9a09288f54e1d744259c88e2c12fb39@haskell.org> Message-ID: <059.bb17883ea708ed149332c4d19e80721e@haskell.org> #13950: IncoherentInstances -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: | IncoherentInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: I think hsyl20 nailed it. I believe this is nothing more than an issue of type variable scoping with `forall` (which I clarified further in #13953). Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:38:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:38:02 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzkyMDog6Ieq5YuV6YG45pOH5a+m5L6L?= In-Reply-To: <044.aa257f029c0cff56b58137cded197a05@haskell.org> References: <044.aa257f029c0cff56b58137cded197a05@haskell.org> Message-ID: <059.63cd0344ad3b1130ba45597e6e1fb169@haskell.org> #13920: 自動選擇實例 -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13950 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => duplicate * related: => #13950 Comment: OK, I'm guessing that #13950 supersedes this issue then. I'll close this issue in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:46:13 -0000 Subject: [GHC] #13954: Source tarballs are missing from the GHC downloads page for older releases. Message-ID: <046.682ce11acff0b73bd91057640f0f65bf@haskell.org> #13954: Source tarballs are missing from the GHC downloads page for older releases. -------------------------------------+------------------------------------- Reporter: maxf130 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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'm trying to download the source tarballs for some old GHC releases (7.4 onwards) and they appear to be missing. There is a link to sources, but no corresponding section: https://www.haskell.org/ghc/download_ghc_7_4_2.html#sources IRC advised me to post a bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:53:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:53:49 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.9e62ca9f7257b30181ded111e38c6969@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,1 +2,1 @@ - confihratiine takes nearly ten minutes. I haven't looked at the code, but + configuration takes nearly ten minutes. I haven't looked at the code, but New description: Compiling the `skylighting` package in profiled and non-profiled configuration takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:55:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:55:54 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.ee93a3b0e7dc18f0ba7e7395d6a05961@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Research Component: Compiler (Type | needed checker) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => Research needed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 15:59:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 15:59:11 -0000 Subject: [GHC] #13952: Liberal coverage condition fails if TypeInType is enabled In-Reply-To: <049.2413136f29a872593d3df719b6ba430c@haskell.org> References: <049.2413136f29a872593d3df719b6ba430c@haskell.org> Message-ID: <064.c2f428a8825f84839b39c2f1c70715be@haskell.org> #13952: Liberal coverage condition fails if TypeInType is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This is expected behavior (see [https://github.com/GetShopTV/swagger2/issues/95 here] for another place where a similar issue arose). The difference between GHC 8.0 and 8.2 is that the datatypes in `GHC.Generics` are now poly-kinded. As a result, the kinds involved in `Expected` are generalized even further: the return kind of `Expected U1` does not determine the kind of `k` in `U1`'s kind (`k -> Type`), causing the liberal coverage condition to fail. This is more apparent if you turn on `-fprint-explicit-kinds`: {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs -fprint-explicit-kinds GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bookkeeper.Internal ( Foo.hs, interpreted ) Foo.hs:19:10: error: • Illegal instance declaration for ‘FromGeneric k (U1 k) book’ The liberal coverage condition fails in class ‘FromGeneric’ for functional dependency: ‘a -> book’ Reason: lhs type ‘U1 k’ does not determine rhs type ‘book’ Un-determined variable: book • In the instance declaration for ‘FromGeneric U1 book’ | 19 | instance (book ~ Expected U1) => FromGeneric U1 book where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This also explains why turning off `TypeInType` fixes the issue, since this kind generalization doesn't occur, and all of the kind variables simply default to `Type`. A simple way to fix this is to just be more explicit about what kinds to use in `Expected`: {{{#!hs type family Expected (a :: k -> Type) :: k where Expected ((l :+: r) :: k -> Type) = (TypeError ('Text "Cannot convert sum types into Books") :: k) Expected (U1 :: k -> Type) = (TypeError ('Text "Cannot convert non-record types into Books") :: k) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 17:58:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 17:58:26 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types Message-ID: <049.a67534eef775638b6e13621c35886744@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: backpack | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the code snippet below, I attempt to use backpack with levity polymorphism: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} unit number-unknown where signature NumberUnknown where import GHC.Types data Number plus :: Number -> Number -> Number multiply :: Number -> Number -> Number module NumberStuff where import NumberUnknown funcA :: Number -> Number -> Number funcA x y = plus x (multiply x y) unit number-int where module NumberUnknown where type Number = Int plus :: Int -> Int -> Int plus = (+) multiply :: Int -> Int -> Int multiply = (*) unit number-unboxed-int where module NumberUnknown where import GHC.Prim type Number = Int# plus :: Int# -> Int# -> Int# plus = (+#) multiply :: Int# -> Int# -> Int# multiply = (*#) unit main where dependency number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] module Main where import NumberStuff main = putStrLn "Hello world!" }}} Compiling this with `ghc --backpack packer.bkp` fails with the following error: {{{ - Type constructor ‘Number’ has conflicting definitions in the module and its hsig file Main module: type Number = GHC.Prim.Int# :: TYPE 'GHC.Types.IntRep Hsig file: data Number The types have different kinds - while checking that number-unboxed-int:NumberUnknown implements signature NumberUnknown in number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] type Number = Int# }}} The error is pretty clear: `Number` can only be instantiated by types of kind `Type` (aka `TYPE LiftedRep`). Even while remaining levity monomorphic, there doesn't seem to be a way to pick a different kind. For example, redefining `Number` in the signature as {{{ data Number :: TYPE IntRep }}} leads to the following immediate failure: {{{ Kind signature on data type declaration has non-* return kind TYPE 'IntRep }}} I do not understand any of the internals of backpack, so I do not understand if there's anything fundamental that makes this impossible. Going one step further, I would like to be able to do something like this (the syntax here is not even currently valid for a backpack signature): {{{ type MyRep :: RuntimeRep data Number :: TYPE MyRep }}} This may be instantiated with something like this: {{{ type MyRep = IntRep type Number = Int# }}} And then end users would be able to monomorphize levity-polymorphic functions. This would be really neat because there is currently no way to do this in GHC. So, I guess there are really two feature requests in here. One is the ability to use unlifted data types with backpack. The other is the ability to use backpack to monomorphize levity-polymorphic functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 18:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 18:00:07 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.0312a1da0ef2ce0e4ab2e1f4f0e401c3@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T12921 Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gnezdo): I hit this problem too. I couldn't quickly locate a prebuilt version of ghc HEAD. Reporting the reproducer here instead. Given this source: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits -- | The floor of log_2(n). type family Log2 n where Log2 1 = 0 Log2 n = Log2 (Div2 n) + 1 -- | The floor of n/2. type family Div2 n where Div2 0 = 0 Div2 1 = 0 Div2 n = Div2 (n - 2) + 1 }}} In ghci I get the following error: {{{ Prelude> Log2 (2 :: GHC.TypeLits.KnownNat) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] Log2_a1P3 :: t_a1P2[tau:1] (CHoleCan: Log2) [W] Log2_a1Px :: t_a1Pw[tau:1] (CHoleCan: Log2)} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 18:05:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 18:05:44 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.0cfd1678e1a67fc78f4035f779478f25@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): Alright, I think I see what you want. So you are targetting applications where you have a potentially-blocking foreign call and therefore can't use `unsafe` calls but want to avoid the cost associated with suspending a Haskell thread. This cost comes in a variety of forms, 1. a stack walk, due to the duplicate computation check in `suspendThread` 2. a few lock operations to safely modify the capability 3. the cost of saving and restoring the thread state to the TSO Judging from this I'd guess this will cost anywhere from hundreds to thousands of cycles (largely depending upon stack depth, I suspect), and consequently it seems plausible that we'd want a way to avoid this. Have you done any characterisation of this? The problem is that, other than perhaps the stack walk, I don't think any of these costs can be avoided. Afterall, we need to save the thread state to the TSO in order to safely GC (since TSOs are GC roots). I suspect it would also be necessary to lock the capability. Consequently, it's really not clear to me that this new call type would pull its weight. It would be helpful if we had actual measurements of how much the various contributions above cost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 18:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 18:57:44 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.1a3eb6bdaa65552b7eb1fa1ab6a3a5c0@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by j.waldmann): I too am seeing this error when doing "make install" after building rc3 from source, configured with a non-standard prefix, on Debian, where the target directory is on an nfs-mounted volume. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 19:51:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 19:51:24 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.3cdae86d1ce02b927dda3b8bdedc8b27@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T12921 Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): gnezdo, I can confirm that your code no longer panics with GHC 8.2: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> Log2 (2 :: GHC.TypeLits.KnownNat) :1:1: error: Data constructor not in scope: Log2 :: t0 -> t1 :1:12: error: • Expecting one more argument to ‘KnownNat’ Expected a type, but ‘KnownNat’ has kind ‘Nat -> Constraint’ • In an expression type signature: KnownNat In the first argument of ‘Log2’, namely ‘(2 :: KnownNat)’ In the expression: Log2 (2 :: KnownNat) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 20:23:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 20:23:27 -0000 Subject: [GHC] #13954: Source tarballs are missing from the GHC downloads page for older releases. In-Reply-To: <046.682ce11acff0b73bd91057640f0f65bf@haskell.org> References: <046.682ce11acff0b73bd91057640f0f65bf@haskell.org> Message-ID: <061.a3807475367c6448d88b8d9c7b09bb32@haskell.org> #13954: Source tarballs are missing from the GHC downloads page for older releases. -------------------------------------+------------------------------------- Reporter: maxf130 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Oh dear, thanks for pointing this out! The issue was a lack of escaping while moving to a new website generation scheme. This should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 20:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 20:37:02 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types In-Reply-To: <049.a67534eef775638b6e13621c35886744@haskell.org> References: <049.a67534eef775638b6e13621c35886744@haskell.org> Message-ID: <064.b7095754674e86da29af676a54c75d64@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: backpack | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:04:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:04:33 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.6dccb12f62c424c3d6c0b676b5deb8e4@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: newcomer, TypeApplications, TypeErrorMessages => TypeApplications, TypeErrorMessages Comment: If I'm daunted by fixing it, it's not for a newcomer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:06:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:06:15 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.d945b94e14c4c6819fd8e44b6019ce26@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T12921 Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gnezdo): I located a binary and after fixing up the code it's working. Thanks! {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import Data.Proxy import GHC.TypeLits -- | The floor of log_2(n). type family Log2 n where Log2 1 = 0 Log2 n = Log2 (Div2 n) + 1 -- | The floor of n/2. type family Div2 n where Div2 0 = 0 Div2 1 = 0 Div2 n = Div2 (n - 2) + 1 valueOf :: forall (n :: Nat) . (KnownNat n) => Integer valueOf = natVal (Proxy :: Proxy n) }}} {{{ $ ./ghc-install/bin/ghci a.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, 1 module loaded. *Main> :set -XDataKinds *Main> :set -XTypeApplications *Main> valueOf @(Log2 3) 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:08:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:08:28 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.2758a4094bfa8ee900c4cff97c1f95ee@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed with comment:8 and, subsequently, the approach in comment:7. I'm not sure about the pattern-match checker, but perhaps that problem can be solved. Happy to take a look at your code if you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:19:41 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.74d6115fce21693d35c3d82196d3282f@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just for the record, I'm back on this. Will have a fix soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:21:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:21:40 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.68df1af585a78bd61626cdbdf9e6410f@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications 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 goldfire): I, for one, am convinced. If someone wants to write a ghc-proposal about this, I'll support it. If no one does, I might on my own someday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:26:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:26:13 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.815fc05e3b6ac38650291da90c30f13f@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications 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 goldfire): Record-construction syntax is not a special application form, so I wouldn't expect this to work. Perhaps we can embellish record-construction to enable this syntax, but it would be a change to the grammar. This smells similar to #12363, asking for type application on infix operators. I think the next step here is a ghc-proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 21:46:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 21:46:58 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.720a39ad6fd1a9b2361716c378c6fe48@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:9 goldfire]: > Happy to take a look at your code if you like. Well, that's the thing... the line: {{{#!hs tcExpr (ExplicitList _ Nothing []) res_ty = tcCheckId nilDataConName res_ty }}} is literally the only change I had to make to make `[] @Int` work. So that's nice. But now exactly one GHC test fails: `T12957`. {{{ =====> T12957(normal) 1 of 1 [0, 0, 0] cd "./pmcheck/should_compile/T12957.run" && "/home/rgscott/Software/ghc4/inplace/test spaces/ghc-stage2" -c T12957.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -fwarn-overlapping-patterns Actual stderr output differs from expected: diff -uw "./pmcheck/should_compile/T12957.run/T12957.stderr.normalised" "./pmcheck/should_compile/T12957.run/T12957.comp.stderr.normalised" --- ./pmcheck/should_compile/T12957.run/T12957.stderr.normalised 2017-07-10 17:44:06.341225345 -0400 +++ ./pmcheck/should_compile/T12957.run/T12957.comp.stderr.normalised 2017-07-10 17:44:06.341225345 -0400 @@ -1,4 +0,0 @@ - -T12957.hs:4:16: warning: [-Woverlapping-patterns (in -Wdefault)] - Pattern match is redundant - In a case alternative: (_ : _) -> ... *** unexpected failure for T12957(normal) }}} And that's where I'm stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 10 22:13:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Jul 2017 22:13:22 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 Message-ID: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- Compiling the package lame-0.1.1 using cabal, with profiling: [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, dist/build/Codec/Audio/LAME.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_soT9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 504681 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is a regression; the package compiles fine with GHC 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 00:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 00:26:12 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments Message-ID: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This currently works {{{#!hs {-# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving #-} import Data.Kind import Data.Functor.Identity class SIEVE f p | p -> f where sIEVE :: p a b -> a -> f b instance SIEVE Identity (->) where sIEVE = (Identity .) newtype ARR a b = ARR (a -> b) deriving newtype (SIEVE Identity) }}} But what if I want a `Sieve I ARR` instance, for `newtype I a = I a` (which is representationally equal to `newtype Identity a = Identity a`)? {{{#!hs {-# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving, RankNTypes, TypeApplications, ScopedTypeVariables, InstanceSigs #-} import Data.Kind import Data.Functor.Identity import Data.Coerce class SIEVE f p | p -> f where sIEVE :: p a b -> a -> f b instance SIEVE Identity (->) where sIEVE = (Identity .) newtype ARR a b = ARR (a -> b) deriving newtype SIEVE I newtype I a = I a }}} generating the following code (this is basically to code generated before, except replacing some `Identity`s with `I`s {{{#!hs instance SIEVE I ARR where sIEVE :: forall a b. ARR a b -> (a -> I b) sIEVE = coerce @((a -> b) -> a -> Identity b) @(ARR a b -> a -> I b) sIEVE }}} GHC should be able to recover `Identity` due to the functional dependency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 00:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 00:27:48 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments In-Reply-To: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> References: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> Message-ID: <066.1c387e9547150ac43bf5b87a0598c61b@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): TODO What if the argument order of `SIEVE` were reversed, as with [https://hackage.haskell.org/package/profunctors-5.2/docs/Data-Profunctor- Sieve.html Sieve].. let's find a way to allow deriving that as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 00:28:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 00:28:45 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments In-Reply-To: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> References: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> Message-ID: <066.8085584a0560c8857d3b2c040693d815@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -41,1 +41,1 @@ - SIEVE I + (SIEVE I) New description: This currently works {{{#!hs {-# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving #-} import Data.Kind import Data.Functor.Identity class SIEVE f p | p -> f where sIEVE :: p a b -> a -> f b instance SIEVE Identity (->) where sIEVE = (Identity .) newtype ARR a b = ARR (a -> b) deriving newtype (SIEVE Identity) }}} But what if I want a `Sieve I ARR` instance, for `newtype I a = I a` (which is representationally equal to `newtype Identity a = Identity a`)? {{{#!hs {-# Language DerivingStrategies, MultiParamTypeClasses, FunctionalDependencies, GeneralizedNewtypeDeriving, RankNTypes, TypeApplications, ScopedTypeVariables, InstanceSigs #-} import Data.Kind import Data.Functor.Identity import Data.Coerce class SIEVE f p | p -> f where sIEVE :: p a b -> a -> f b instance SIEVE Identity (->) where sIEVE = (Identity .) newtype ARR a b = ARR (a -> b) deriving newtype (SIEVE I) newtype I a = I a }}} generating the following code (this is basically to code generated before, except replacing some `Identity`s with `I`s {{{#!hs instance SIEVE I ARR where sIEVE :: forall a b. ARR a b -> (a -> I b) sIEVE = coerce @((a -> b) -> a -> Identity b) @(ARR a b -> a -> I b) sIEVE }}} GHC should be able to recover `Identity` due to the functional dependency. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 00:42:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 00:42:26 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.699c7079b22ed6fe03a6390c777f095a@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications 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 Iceland_jack): Hm this is confusing {{{ > Identity { runIdentity = 42 } Identity 42 > (Identity) { runIdentity = 42 } :21:1: error: • Couldn't match expected type ‘Identity a1’ with actual type ‘a0 -> Identity a0’ • In the expression: (Identity) {runIdentity = 42} In an equation for ‘it’: it = (Identity) {runIdentity = 42} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 01:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 01:39:23 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.a2fcd198bea2be5ca9f1603550ec7aeb@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications 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 goldfire): comment:3 follows directly from the [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-520003.15.2 Report]. Note that `(Identity {}) { runIdentity = 42 }` works: a record construction (with an empty field-list) followed by a record-update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 01:42:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 01:42:04 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.6e3e2349ac8b8659b666e67edf54f71d@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): > Alright, I think I see what you want. So you are targetting applications where you have a potentially-blocking foreign call and therefore can't use `unsafe` calls but want to avoid the cost associated with suspending a Haskell thread. Exactly! For example current I/O manager first perform an unsafe read and check if result is eAgain, but for regular file it will never return eAgain, which turn this unsafe read into a blocking read. If unfortunately OS didn't manage page cache for us, we end up with a long capacity blocking read. > The problem is that, other than perhaps the stack walk, I don't think any of these costs can be avoided. Afterall, we need to save the thread state to the TSO in order to safely GC (since TSOs are GC roots). I suspect it would also be necessary to lock the capability. Is there a way to do it lazily? By say lazily i meaning, can we just perform the FFI call and mark the capacity with some kind of `SYNC` flag. If a GC thread is asking for sync during FFI, then let it perform these stack saving for us. Otherwise we just happily continue, and saving all the overheads. I think this might work since once we enter a FFI call, the haskell thread's stack are not touch anymore, and the whole capacity is freezed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 01:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 01:54:28 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.02dec996fc98f202aaa51763bd3a3aa1@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Then just accept the new output. :) The test case for #12957 is not testing to see if GHC can report a redundant pattern match -- it's checking to make sure GHC avoids a panic. This change would bring the behavior around lists in line with that for other datatypes. Note that `case Nothing of Just _ -> ...` does not report a redundant match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 02:01:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 02:01:45 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments In-Reply-To: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> References: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> Message-ID: <066.510f1311c68bc4f0dfbf594ef1757f59@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): This doesn't strike me as a very good idea, for a simple reason: it's quite possible you might also have `instance SIEVE I (->)` in scope, which might behave differently from `instance Sieve Identity (->)`. Allowing this sort of thing would make deriving with MPTCs very unpredictable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 02:10:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 02:10:46 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.ad3c884d3e3085038062df65b6f98ad5@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mpickering (added) Comment: Huh, I certainly didn't realize that lists were unique in this regard. In fact, the warning even goes away if you replace `[]` with an empty string literal! {{{ λ> case [] of (_:_) -> case () of a -> undefined :5:12: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: (_ : _) -> ... *** Exception: :5:1-45: Non-exhaustive patterns in case λ> case "" of (_:_) -> case () of a -> undefined *** Exception: :6:1-45: Non-exhaustive patterns in case }}} In that case, I'm slightly more comfortable with making this change. But just in case, I'll cc mpickering, the author of the `T12957` test, to make sure he's comfortable with this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 02:51:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 02:51:01 -0000 Subject: [GHC] #13958: Ghc linking failure for 8.2.1 rc3 on Alpine Linux Message-ID: <046.191e3f9d3befb75a63fa258bf0a5943b@haskell.org> #13958: Ghc linking failure for 8.2.1 rc3 on Alpine Linux -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Bisected this down to commit 2785ef0e31a123400da950ffafebe6cb1ce3f4eb between rc2 and rc3. rc2 builds fine. This is on Alpine Linux which uses musl libc primarily and gcc/binutils patched for it as well (mostly PIE related), if wanted I can provide a Dockerfile to reproduce the issue more easily. Note that the switch provided by that commit, --disable-ld-override allows rc3 to link stage 2 properly again. But the error encountered with no override and when specifying the ld to use via configure, in this case ld.gold is this: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -packag e-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc- boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id bytestring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddo ck/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/driver/ResponseFile.hs -o utils/haddock/dist/build/ResponseFile.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -packag e-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc- boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id by testring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- api/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc-boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id by testring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddo ck/dist/build -stubdir utils/haddock/dist/build -c utils/haddock /haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -packag e-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc- boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id by testring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddo ck/dist/build -stubdir utils/haddock/dist/build -c utils/haddock /haddock-library/src/Documentation/Haddock/Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -packag e-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc- boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id by testring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddo ck/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/dist/build/haddock/autogen/Paths_haddock.hs -o utils/haddock/dist/build/Paths_haddock.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/sr c -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -packag e-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.0 -package-id ghc- boot-8.2.0.20170704 -package-id ghc-8.2.0.20170704 -package-id by testring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddo ck/dist/build -stubdir utils/haddock/dist/build -c utils/haddock /haddock-library/src/Documentation/Haddock/Utf8.hs -o utils/haddock/dist/build/Documentation/Haddock/Utf8.dyn_o Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.soError relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.soError relocating /home/build/aport s/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build/libHSrts_thr- ghc8.2.0.20170704.soError relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found: my_task: symbol not found : my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found: my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not foundError relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so : my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found Error relocating /home/build/aports/testing/ghc/src/ghc-8.2.0.20170704/rts/dist/build /libHSrts_thr-ghc8.2.0.20170704.so: my_task: symbol not found make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Error 127 make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Error 127 make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Utf8.dyn_o] Error 127 make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 127 make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Paths_haddock.dyn_o] Error 127 make: *** [Makefile:127: all] Error 2 >>> ERROR: ghc: all failed >>> ghc: Uninstalling dependencies... }}} I can attach the log file that comes from or just give a Dockerfile one can use to replicate things and debug directly. But there is a workaround so probably not a super critical bug from my perspective. I'm not sure how well this relates to the issues listed in that commit: #13541, #13810, #13883 so I'm just leaving those out of this issue for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 04:08:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 04:08:04 -0000 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@haskell.org> References: <042.4664e49fbb66d0162bc19b3088fe61ba@haskell.org> Message-ID: <057.16b4e68db47b8f67769a5c292a785585@haskell.org> #2515: Flag to suppress orphan instance warnings -------------------------------------+------------------------------------- Reporter: tim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by buecking): * cc: buecking (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 04:14:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 04:14:29 -0000 Subject: [GHC] #10150: Suppress orphan instance warning per instance In-Reply-To: <045.dd025a940793eea395715281eec0b7db@haskell.org> References: <045.dd025a940793eea395715281eec0b7db@haskell.org> Message-ID: <060.d2b5712cad3b5e697c99b420ad65aef5@haskell.org> #10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #602, #13841 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by buecking): * cc: buecking (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 04:45:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 04:45:20 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types In-Reply-To: <049.a67534eef775638b6e13621c35886744@haskell.org> References: <049.a67534eef775638b6e13621c35886744@haskell.org> Message-ID: <064.bb07336e4df1895246ad97862fbc4a3f@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: backpack | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 06:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 06:54:03 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious Message-ID: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Currently, we have: {{{#!hs substTyVar :: TCvSubst -> TyVar -> Type substTyVar (TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty Nothing -> TyVarTy tv }}} But as Richard pointed out to me, the `Nothing` case is flat-out wrong. If `tv` isn't in the substitution, we need to check if any of the variables in `tv`'s kind are in the substitution, and if so, apply the substitution to them. Fixing this might seem straightforward enough: {{{#!diff diff --git a/compiler/types/TyCoRep.hs b/compiler/types/TyCoRep.hs index 5ac63e5..4f7d650 100644 --- a/compiler/types/TyCoRep.hs +++ b/compiler/types/TyCoRep.hs @@ -2191,11 +2191,11 @@ subst_ty subst ty go (CoercionTy co) = CoercionTy $! (subst_co subst co) substTyVar :: TCvSubst -> TyVar -> Type -substTyVar (TCvSubst _ tenv _) tv +substTyVar subst@(TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty - Nothing -> TyVarTy tv + Nothing -> TyVarTy (updateTyVarKind (substTyUnchecked subst) tv) substTyVars :: TCvSubst -> [TyVar] -> [Type] substTyVars subst = map $ substTyVar subst }}} But note that I'm using `substTyUnchecked`, not `substTy`, since if you try using the latter, GHC will pretty quickly fall over on a `./validate --slow` build, as `substTy`'s assertions are violated all over the place. I'm fairly certain I know why the assertions would be tripping up, however. To build most of the in-scope sets used for `substTyVar`'s substitutions, the `mkVarSet :: [Var] -> VarSet` function is used. But `mkVarSet` only grabs the `Unique`s of the type variables themselves, not the variables in the kind of each type variable. This means the in-scope sets will frequently be too narrow to encompass the kind variables, which absolutely must be in the set if we want to change `substTyVar` as described above. I'm not sure what the solution is here. Perhaps we should be using a variant of `mkVarSet` called `mkTyVarSet` that grabs the `Unique`s of the kind variables as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 09:02:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 09:02:57 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.a2a77f4cb1b61842bda641c7c564b3fa@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications 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 Iceland_jack): `Identity @Int {}` would work as well then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 12:44:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 12:44:38 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.13127a98e4ee9e8338f98080220513cd@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): J.waldmann, is the NFS lock daemon running? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 13:32:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 13:32:20 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types In-Reply-To: <049.a67534eef775638b6e13621c35886744@haskell.org> References: <049.a67534eef775638b6e13621c35886744@haskell.org> Message-ID: <064.e0bb95a5f8dd3ef8879b86d55cfadf6e@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: backpack | LevityPolymorphism 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 ezyang): Yeah, this doesn't look something GHC allows right now, because `data` declarations have to have kind `*`, and there is no way to define an abstract type with different kind. But it seems like it should be possible, we just have to relax some of the checks GHC does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 14:37:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 14:37:58 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types In-Reply-To: <049.a67534eef775638b6e13621c35886744@haskell.org> References: <049.a67534eef775638b6e13621c35886744@haskell.org> Message-ID: <064.f99144e001f837325231f6b13e760ca1@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: backpack | LevityPolymorphism 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 Iceland_jack): UnliftedDataTypes is relevant -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 15:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 15:26:47 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.153db32730ac0e0ca423901fc1973301@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications 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 RyanGlScott): Assuming the proposal in this ticket were implemented, then yes, `Identity @Int {}` would be a perfectly cromulent thing to do. `Identity {}` is a record construction that doesn't specify any record names, so all fields would be initialized to `⊥`. So `Identity @Int {}` is essentially `Identity (⊥ :: Int)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #12390: List rules for `Coercible` instances In-Reply-To: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> References: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> Message-ID: <066.372e4551fa8d6b84e6dc06d475fbe8d7@haskell.org> #12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: tellah Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghci059 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3634 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"905dc8bc74bebf5370eb9237cc8756cd9fe871ae/ghc" 905dc8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="905dc8bc74bebf5370eb9237cc8756cd9fe871ae" Make ':info Coercible' display an arbitrary string (fixes #12390) This change enables the addition of an arbitrary string to the output of GHCi's ':info'. It was made for Coercible in particular but could be extended if desired. Updates haddock submodule. Test Plan: Modified test 'ghci059' to match new output. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #12390 Differential Revision: https://phabricator.haskell.org/D3634 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable In-Reply-To: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> References: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> Message-ID: <058.f390716490bf81973edb7e2d94e6c557@haskell.org> #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 Ben Gamari ): In [changeset:"6cff2caddd9b329272a7d6965b20432e8078e0d8/ghc" 6cff2cad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6cff2caddd9b329272a7d6965b20432e8078e0d8" Add testcase for T13818 Annotations currently fail to type check if they annotation cannot be loaded into ghci, such as when built with -fno-code. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13818 Differential Revision: https://phabricator.haskell.org/D3701 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13830: '+RTS -s' gives incorrect value for work balance in some cases In-Reply-To: <043.14e010bc8c8133d891369e32e6e80a21@haskell.org> References: <043.14e010bc8c8133d891369e32e6e80a21@haskell.org> Message-ID: <058.9088d7d8f38317f9c85c68645ffe74fa@haskell.org> #13830: '+RTS -s' gives incorrect value for work balance in some cases -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3658 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7c9e356de1114ab3e31f2d6d03e83672076dd533/ghc" 7c9e356d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7c9e356de1114ab3e31f2d6d03e83672076dd533" Fix Work Balance computation in RTS stats An additional stat is tracked per gc: par_balanced_copied This is the the number of bytes copied by each gc thread under the balanced lmit, which is simply (copied_bytes / num_gc_threads). The stat is added to all the appropriate GC structures, so is visible in the eventlog and in GHC.Stats. A note is added explaining how work balance is computed. Remove some end of line whitespace Test Plan: ./validate experiment with the program attached to the ticket examine code changes carefully Reviewers: simonmar, austin, hvr, bgamari, erikd Reviewed By: simonmar Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #13830 Differential Revision: https://phabricator.haskell.org/D3658 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13899: Improve [-Wmissing-home-modules] error message In-Reply-To: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> References: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> Message-ID: <059.9c94322d806b22aea45ac0a6ad026c0d@haskell.org> #13899: Improve [-Wmissing-home-modules] error message -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3686 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b0c9f34aa3da914524ef37294bba78afefc3ada7/ghc" b0c9f34/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0c9f34aa3da914524ef37294bba78afefc3ada7" Improve Wmissing-home-modules warning under Cabal Reviewers: hvr, alanz, austin Reviewed By: alanz Subscribers: rwbarton, thomie GHC Trac Issues: #13899 Differential Revision: https://phabricator.haskell.org/D3686 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13919: Incorrect unused top binding warning when interacting with GHC.Generics In-Reply-To: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> References: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> Message-ID: <059.ae5ce47ac273bc4e7f2664dbae332f5c@haskell.org> #13919: Incorrect unused top binding warning when interacting with GHC.Generics -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1954 | Differential Rev(s): Phab:D3704 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"15fcd9adb75b95b32fbe08d066a2ada5f298d667/ghc" 15fcd9ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15fcd9adb75b95b32fbe08d066a2ada5f298d667" Suppress unused warnings for selectors for some derived classes Although derived `Read`, `Show`, and `Generic` instances technically don't //use// the record selectors of the data type for which an instance is being derived, the derived code is affected by the //presence// of record selectors. As a result, we should suppress `-Wunused-binds` for those record selectors when deriving these classes. This is accomplished by threading through more information from `hasStockDeriving`. Test Plan: make test TEST=T13919 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13919 Differential Revision: https://phabricator.haskell.org/D3704 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13922: Sort output of failed tests. In-Reply-To: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> References: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> Message-ID: <062.d153a644bdb54bcd9f1d866a6437468c@haskell.org> #13922: Sort output of failed tests. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3705 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cb8db9bcbdbe5008fbefb3ce262a8f06fb7366da/ghc" cb8db9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb8db9bcbdbe5008fbefb3ce262a8f06fb7366da" Sort list of failed tests for easier comparison between runs Test Plan: Running the testsuite. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13922 Differential Revision: https://phabricator.haskell.org/D3705 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13825: Allow multiple constructor fields occupy the same word In-Reply-To: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> References: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> Message-ID: <061.731c79d045a26a71631aedf714978f7d@haskell.org> #13825: Allow multiple constructor fields occupy the same word -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #605 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fe6618b14712b829b8675fc6024dd33e9598d09a/ghc" fe6618b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe6618b14712b829b8675fc6024dd33e9598d09a" ByteCodeGen: use depth instead of offsets in BCEnv This is based on unfinished work in D38 started by Simon Marlow and is the first step for fixing #13825. (next step use byte-indexing for stack) The change boils down to adjusting everything in BCEnv by +1, which simplifies the code a bit. I've also looked into a weird stack adjustement that we did in `getIdValFromApStack` and moved it to `ByteCodeGen` to just keep everything in one place. I've left a comment about this. Signed-off-by: Michal Terepeta Test Plan: ./validate Reviewers: austin, hvr, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: simonmar, rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3708 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.a2978edd6f3fc5516e77fc0d62161dcb@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari ): In [changeset:"b8f33bc6b738b0378976e42b79369f0e53b680c7/ghc" b8f33bc6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b8f33bc6b738b0378976e42b79369f0e53b680c7" Always allow -staticlib the `-staticlib` flag is currently only supported on apple platforms, due to the avaiablity of libtool (the apple version, which is unlike the gnu version). This however prevents the use of -staticlib in cases where it would be beneficial as well. The functionality that `-staticlib` uses from `libtool` can be stubbed with a small script like the following: ``` #!/bin/bash # This script pretends to be libtool. And supports # only a limited set of flags. # # It is supposed to be a stand in for libtool -static, whic # creates a static archive. This is done by locating all -l # libs in the provied -L library paths, and building an # MRI script to create the final archive from all the libraries, and # other provided inputs. # name=${0##*/} target=${name%-*} set -e ldflags_L=() ldflags_l=() output="" inputs=() STATIC=0 DYNAMIC=1 mode=$DYNAMIC verbose=0 # find_lib path path path path function find_lib () { lib=$1; shift 1; for dir in $@; do if [ -f "$dir/$lib" ]; then echo "$dir/$lib" break fi done } while [ "$#" -gt 0 ]; do case "$1" in -v|--verbose) verbose=1; shift 1;; -o) output="$2"; shift 2;; -L*) ldflags_L+=("${1:2:${#1}-2}"); shift 1;; -l*) ldflags_l+=("lib${1:2:${#1}-2}.a"); shift 1;; -static) mode=$STATIC; shift 1;; -dynamic) mode=$DYNAMIC; shift 1;; -Wl,*) ldflags+=("${1#*,}"); shift 1;; -*) echo "unknown option: $1" >&2; exit 1;; *) inputs+=("$1"); shift 1;; esac done if [ ! $mode == $STATIC ]; then echo "-dynamic not supported!" >&2; exit 1; fi MRI="create ${output}\n" for input in "${ldflags_l[@]}"; do lib=$(find_lib $input ${ldflags_L[@]}) if [ -z $lib ]; then echo "Failed to find lib $input" >&2 exit 1 else MRI+="addlib $lib\n" continue fi done for input in "${inputs[@]}"; do MRI+="addmod $input\n" done MRI+="save\nend\n" echo -e "$MRI" | $target-ar -M $target-ranlib $output ``` if `ar` supports MRI scripts. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3706 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:42:15 -0000 Subject: [GHC] #13875: ApplicativeDo desugaring is lazier than standard desugaring In-Reply-To: <045.2eda858359df0999208d04da5f95a1da@haskell.org> References: <045.2eda858359df0999208d04da5f95a1da@haskell.org> Message-ID: <060.eb9887a24dea5f135a959d3b47091e74@haskell.org> #13875: ApplicativeDo desugaring is lazier than standard desugaring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ccb849f8ea39582d2cfc5c045abe9768992dccb6/ghc" ccb849f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ccb849f8ea39582d2cfc5c045abe9768992dccb6" users-guide/rel-notes: Describe #13875 fix Test Plan: Read it. Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13875 Differential Revision: https://phabricator.haskell.org/D3710 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:44:03 -0000 Subject: [GHC] #13919: Incorrect unused top binding warning when interacting with GHC.Generics In-Reply-To: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> References: <044.a36486aa599d6ae8f36c85b59d7fb449@haskell.org> Message-ID: <059.bd3f3a21cca7a28c330144576637cef8@haskell.org> #13919: Incorrect unused top binding warning when interacting with GHC.Generics -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1954 | Differential Rev(s): Phab:D3704 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:44:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:44:27 -0000 Subject: [GHC] #13899: Improve [-Wmissing-home-modules] error message In-Reply-To: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> References: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> Message-ID: <059.7e0ba733a7928110f8f8f78f866c1e13@haskell.org> #13899: Improve [-Wmissing-home-modules] error message -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3686 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:44:56 -0000 Subject: [GHC] #13830: '+RTS -s' gives incorrect value for work balance in some cases In-Reply-To: <043.14e010bc8c8133d891369e32e6e80a21@haskell.org> References: <043.14e010bc8c8133d891369e32e6e80a21@haskell.org> Message-ID: <058.177524579aeaba7ebfb31427d9a59245@haskell.org> #13830: '+RTS -s' gives incorrect value for work balance in some cases -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3658 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 17:45:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 17:45:18 -0000 Subject: [GHC] #12390: List rules for `Coercible` instances In-Reply-To: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> References: <051.b98e23ec385e9c48fab8abae2b183162@haskell.org> Message-ID: <066.f36e257bfa2cbe671b48960939d1312f@haskell.org> #12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: tellah Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghci059 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3634 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:16:25 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 Message-ID: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This is unfortunately a closed-source codebase I'm experiencing this with, but we get a GHC panic with a small/not-doing-anything-crazy codebase: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op return To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 118123 }}} When upping to `-fsimpl-tick-factor=150`, the error is a little different: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 177190 }}} Upping to 200 makes the issue go away. We're building with `ghc-options: -fhpc` Before each build, we remove all .tix files and the .hpc directory At the point this error fires, we're compiling the 6th module of 9. The first 6 modules to compile only have a total of 635 lines of code. To address issues I've seen in other similar tickets: - There are no recursive module imports - We don't use any `{-# INLINE #-}` or similar pragmas - There is no Template Haskell other than a `makeLenses ''App` for a small Snaplet. - We don't have any "very"/exponentially recursive code - We don't use any unboxed tuples (there *is* ST code in a module that's compiled, but not the one ghc panics on) - We don't use type families - We don't use TypeRep or Typeable - We don't use Generic When this error occurs, it fails on a module which has very little code in it. It's mainly a list of ~200-300 Query[0] values, using OverloadedStrings. I notice Query's `mappend`, which we use, is `INLINE`d. Please let me know if I can provide more detail! [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs /Database-PostgreSQL-Simple-Types.html#t:Query -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:19:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:19:49 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.96ba23ba5094ae55815fd710fafc7a2d@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): >> The problem is that, other than perhaps the stack walk, I don't think any of these costs can be avoided. Afterall, we need to save the thread state to the TSO in order to safely GC (since TSOs are GC roots). I suspect it would also be necessary to lock the capability. > > Is there a way to do it lazily? By say lazily i meaning, can we just perform the FFI call and mark the capacity with some kind of SYNC flag. If a GC thread is asking for sync during FFI, then let it perform these stack saving for us. Otherwise we just happily continue, and saving all the overheads. I'll assume by "it" you mean the thread-state save. I don't believe it is possible; afterall, there may be thread state (which may contain reference to heap objects) sitting in machine registers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:27:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:27:32 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.0aa9f41c215b11230c468f79ed784568@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): In general it is expected that some modules will occasionally need to have the tick limit bumped in order to compile. Afterall, the simplifier tick mechanism is merely a heuristic. In your case it sounds like this is a rather small and simple program, which makes the failure a bit more surprising. However, it's hard to tell without seeing actual code. It would be quite helpful if you could try to reduce the problem down to a something that you can share. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:27:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:27:42 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.ab711c594127a40a1cd8fbd1fa532feb@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:28:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:28:24 -0000 Subject: [GHC] #13922: Sort output of failed tests. In-Reply-To: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> References: <047.5e2366e8d5e5e11c5397a811ee1ef7c6@haskell.org> Message-ID: <062.0bc9e4398fe420301815c61851602e4a@haskell.org> #13922: Sort output of failed tests. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: lowest | Milestone: 8.4.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3705 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:19 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.70ac6004f646e8180c64ea74c829c3ef@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3720 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ea751248d80efe7633a31120da56e9a31b6820ff/ghc" ea75124/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea751248d80efe7633a31120da56e9a31b6820ff" Fix logic error in GhcMake.enableCodeGenForTH transitive_deps_set was incorrect, it was not considering the dependencies of dependencies in some cases. I've corrected it and tidied it up a little. The test case from leftaroundabout, as linked to from the ticket, is added with small modifications to flatten directory structure. Test Plan: make test TEST=T13949 Reviewers: austin, bgamari, alexbiehl Reviewed By: alexbiehl Subscribers: rwbarton, thomie, alexbiehl GHC Trac Issues: #13949 Differential Revision: https://phabricator.haskell.org/D3720 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:19 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.1d216ace4b5170177049e9ba36d438bc@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3547 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba46e63f3d6f7d0438a0262f6711f8a219c703bc/ghc" ba46e63f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba46e63f3d6f7d0438a0262f6711f8a219c703bc" Fix #13948 by being pickier about when to suggest DataKinds Commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (#13568) made GHC a bit too cavalier in suggesting when data constructors are in scope (and suggesting the use of `DataKinds`). This tones down the suggestions so that `DataKinds` is only suggested if a data constructor of that name is actually in scope (previously, it would always suggest, even if it was out of scope). Fixes #13948. Test Plan: ./validate Reviewers: mpickering, austin, bgamari Reviewed By: mpickering Subscribers: rwbarton, thomie GHC Trac Issues: #13948 Differential Revision: https://phabricator.haskell.org/D3719 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:19 -0000 Subject: [GHC] #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 In-Reply-To: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> References: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> Message-ID: <065.bfdc0cb258ffcfd6176823f8d6766ff2@haskell.org> #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13568 | Differential Rev(s): Phab:D3719 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba46e63f3d6f7d0438a0262f6711f8a219c703bc/ghc" ba46e63f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba46e63f3d6f7d0438a0262f6711f8a219c703bc" Fix #13948 by being pickier about when to suggest DataKinds Commit 343cb32d0983f576d344a2d04a35c3fd6eecf2c5 (#13568) made GHC a bit too cavalier in suggesting when data constructors are in scope (and suggesting the use of `DataKinds`). This tones down the suggestions so that `DataKinds` is only suggested if a data constructor of that name is actually in scope (previously, it would always suggest, even if it was out of scope). Fixes #13948. Test Plan: ./validate Reviewers: mpickering, austin, bgamari Reviewed By: mpickering Subscribers: rwbarton, thomie GHC Trac Issues: #13948 Differential Revision: https://phabricator.haskell.org/D3719 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:19 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.37092e1c94fef21e4adb594e6d815e34@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3718 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"85ac65c5f0b057f1b07ed7bf9a8d9aeae4ce1390/ghc" 85ac65c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85ac65c5f0b057f1b07ed7bf9a8d9aeae4ce1390" Fix #13947 by checking for unbounded names more Commit 2484d4dae65c81f218dcfe494b963b2630bb8fa6 accidentally dropped a call to `isUnboundName` in an important location. This re-adds it. Fixes #13947. Test Plan: make test TEST=T13947 Reviewers: adamgundry, austin, bgamari Reviewed By: adamgundry Subscribers: rwbarton, thomie GHC Trac Issues: #13947 Differential Revision: https://phabricator.haskell.org/D3718 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:19 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.de851ce23ca05ad9d44a71efb5a49fe8@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3717 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ef7fd0ae8b519b3cd05349753a0e145112c26b67/ghc" ef7fd0a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ef7fd0ae8b519b3cd05349753a0e145112c26b67" Parenthesize infix type names in data declarations in TH printer Previously datatype names were not paraenthesized (#13887). Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3717 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:36:58 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.7ff9f6d5454d89742d9ac09caff2517b@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3720 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:37:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:37:54 -0000 Subject: [GHC] #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 In-Reply-To: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> References: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> Message-ID: <065.b3d013e68d36a2b0d2818a5f84cae2d6@haskell.org> #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13568 | Differential Rev(s): Phab:D3719 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:38:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:38:23 -0000 Subject: [GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor In-Reply-To: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> References: <050.cb69526e5f28bcbf4d8dc963193d267f@haskell.org> Message-ID: <065.9f5d7036af66c349991da7a11f3bb428@haskell.org> #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3718 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 18:38:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 18:38:42 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.8426ad4e5828c9713ee9702ae282eac2@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 19:05:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 19:05:29 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.ac8b5ffb43639e3a19e1c83f7b228062@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Description changed by tom-bop: @@ -1,2 +1,75 @@ - This is unfortunately a closed-source codebase I'm experiencing this with, - but we get a GHC panic with a small/not-doing-anything-crazy codebase: + **Update**: I've been able to provide a much simpler test case for this + error: + + Broken.hs: + + {{{ + #!haskell + {-# LANGUAGE OverloadedStrings #-} + + module Broken (breaks) where + + import Database.PostgreSQL.Simple.Types (Query(..)) + + breaks :: [(Query, Query)] + breaks = [ + ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + , ("query", "query") + ] + }}} + + broken.cabal: + + {{{ + name: broken + version: 0.1.0.0 + build-type: Simple + cabal-version: >=1.10 + + library + exposed-modules: + Broken + other-extensions: + OverloadedStrings + build-depends: + base + -- >=4.9 && <4.10 + , postgresql-simple + -- >=0.5 && <0.6 + default-language: Haskell2010 + }}} + + `cabal install broken.cabal` results in: + + {{{ + ghc: panic! (the 'impossible' happened) + (GHC version 8.0.2 for x86_64-unknown-linux): + Simplifier ticks exhausted + When trying UnfoldingDone ord + To increase the limit, use -fsimpl-tick-factor=N (default 100) + If you need to do this, let GHC HQ know, and what factor you needed + To see detailed counts use -ddump-simpl-stats + Total ticks: 20731 + + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + }}} + + ---- + + ---- + + **Older info:** + + + ~~This is unfortunately a closed-source codebase I'm experiencing this + with, but we get a GHC panic with a small/not-doing-anything-crazy + codebase:~~ New description: **Update**: I've been able to provide a much simpler test case for this error: Broken.hs: {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} module Broken (breaks) where import Database.PostgreSQL.Simple.Types (Query(..)) breaks :: [(Query, Query)] breaks = [ ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") ] }}} broken.cabal: {{{ name: broken version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library exposed-modules: Broken other-extensions: OverloadedStrings build-depends: base -- >=4.9 && <4.10 , postgresql-simple -- >=0.5 && <0.6 default-language: Haskell2010 }}} `cabal install broken.cabal` results in: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone ord To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 20731 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} ---- ---- **Older info:** ~~This is unfortunately a closed-source codebase I'm experiencing this with, but we get a GHC panic with a small/not-doing-anything-crazy codebase:~~ {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op return To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 118123 }}} When upping to `-fsimpl-tick-factor=150`, the error is a little different: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 177190 }}} Upping to 200 makes the issue go away. We're building with `ghc-options: -fhpc` Before each build, we remove all .tix files and the .hpc directory At the point this error fires, we're compiling the 6th module of 9. The first 6 modules to compile only have a total of 635 lines of code. To address issues I've seen in other similar tickets: - There are no recursive module imports - We don't use any `{-# INLINE #-}` or similar pragmas - There is no Template Haskell other than a `makeLenses ''App` for a small Snaplet. - We don't have any "very"/exponentially recursive code - We don't use any unboxed tuples (there *is* ST code in a module that's compiled, but not the one ghc panics on) - We don't use type families - We don't use TypeRep or Typeable - We don't use Generic When this error occurs, it fails on a module which has very little code in it. It's mainly a list of ~200-300 Query[0] values, using OverloadedStrings. I notice Query's `mappend`, which we use, is `INLINE`d. Please let me know if I can provide more detail! [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs /Database-PostgreSQL-Simple-Types.html#t:Query -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 19:06:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 19:06:00 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.588e1518beb51675a3452bb94d1cc0c1@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 tom-bop): Thanks @bgamari - I've been able to simplify it substantially and provide a repo case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 19:07:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 19:07:29 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.93f2471af454928a00d4f6d787c4c24b@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Description changed by tom-bop: @@ -12,1 +12,1 @@ - import Database.PostgreSQL.Simple.Types (Query(..)) + import Database.PostgreSQL.Simple.Types (Query) New description: **Update**: I've been able to provide a much simpler test case for this error: Broken.hs: {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} module Broken (breaks) where import Database.PostgreSQL.Simple.Types (Query) breaks :: [(Query, Query)] breaks = [ ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") ] }}} broken.cabal: {{{ name: broken version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library exposed-modules: Broken other-extensions: OverloadedStrings build-depends: base -- >=4.9 && <4.10 , postgresql-simple -- >=0.5 && <0.6 default-language: Haskell2010 }}} `cabal install broken.cabal` results in: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone ord To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 20731 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} ---- ---- **Older info:** ~~This is unfortunately a closed-source codebase I'm experiencing this with, but we get a GHC panic with a small/not-doing-anything-crazy codebase:~~ {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op return To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 118123 }}} When upping to `-fsimpl-tick-factor=150`, the error is a little different: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 177190 }}} Upping to 200 makes the issue go away. We're building with `ghc-options: -fhpc` Before each build, we remove all .tix files and the .hpc directory At the point this error fires, we're compiling the 6th module of 9. The first 6 modules to compile only have a total of 635 lines of code. To address issues I've seen in other similar tickets: - There are no recursive module imports - We don't use any `{-# INLINE #-}` or similar pragmas - There is no Template Haskell other than a `makeLenses ''App` for a small Snaplet. - We don't have any "very"/exponentially recursive code - We don't use any unboxed tuples (there *is* ST code in a module that's compiled, but not the one ghc panics on) - We don't use type families - We don't use TypeRep or Typeable - We don't use Generic When this error occurs, it fails on a module which has very little code in it. It's mainly a list of ~200-300 Query[0] values, using OverloadedStrings. I notice Query's `mappend`, which we use, is `INLINE`d. Please let me know if I can provide more detail! [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs /Database-PostgreSQL-Simple-Types.html#t:Query -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 19:26:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 19:26:39 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.93153672ddfe15afb3304183bca77431@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"be04c16b0e5fe9d50562e0868b890b0f9b778a41/ghc" be04c16b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be04c16b0e5fe9d50562e0868b890b0f9b778a41" StgLint: Don't loop on tycons with runtime rep arguments Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13941 Differential Revision: https://phabricator.haskell.org/D3714 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 19:26:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 19:26:39 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.7d871ef128109d753701b4134ba059c3@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13810, #13739 | Differential Rev(s): Phab:D3449, Wiki Page: | Phab:D3694 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fcd2db14368fc6e0d35b13535a9663cfab7080a7/ghc" fcd2db14/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fcd2db14368fc6e0d35b13535a9663cfab7080a7" configure: Ensure that we don't set LD to unusable linker Previously if we found an unusable linker in PATH (e.g. ld.lld on OS X) we would notice the -fuse-ld=... was broken, but neglected to reset LD to a usable linker. This resulted in brokenness on OS X when lld is in PATH. Test Plan: Validate on OS X with lld in PATH Reviewers: austin, hvr, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, erikd, angerman GHC Trac Issues: #13541 Differential Revision: https://phabricator.haskell.org/D3713 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:00:27 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.5a7be295d774fb330a32ca1dd063e672@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12494.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by habibalamin): * testcase: => libraries/base/tests/T12494.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:35:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:35:23 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.cee3c6e0202ab3ec43526c8469e0ef47@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:41:37 -0000 Subject: [GHC] #13937: @progbits is used incorrectly throughout GHC In-Reply-To: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> References: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> Message-ID: <061.ead33fdac19d529bd4eaa0e1a66f8bb1@haskell.org> #13937: @progbits is used incorrectly throughout GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3712 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9b9f978fdcd13ff7b2a9b7391e02dff06da622a0/ghc" 9b9f978f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b9f978fdcd13ff7b2a9b7391e02dff06da622a0" Use correct section types syntax for architecture Previously GHC would always assume that section types began with `@` while producing assembly, which is not true. For instance, in ARM assembly syntax section types begin with `%`. This abstracts out section type pretty- printing and adjusts it to correctly account for the target architectures assembly flavor. Reviewers: austin, hvr, Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie, erikd GHC Trac Issues: #13937 Differential Revision: https://phabricator.haskell.org/D3712 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:42:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:42:04 -0000 Subject: [GHC] #13937: @progbits is used incorrectly throughout GHC In-Reply-To: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> References: <046.3a508e4e57389cb1e41e8199098cc90c@haskell.org> Message-ID: <061.ae0930518e5f121c1c21760583a6d0bd@haskell.org> #13937: @progbits is used incorrectly throughout GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3712 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:56:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:56:48 -0000 Subject: [GHC] #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable In-Reply-To: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> References: <043.c516255f7dad6e8df1c98c0695419dd5@haskell.org> Message-ID: <058.a696ca78cad6a9334fe2ab2af76007df@haskell.org> #13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | annotations/should_compile/T13818 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * testcase: => annotations/should_compile/T13818 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 20:58:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 20:58:39 -0000 Subject: [GHC] #13949: Haddock fails to typecheck an example with TemplateHaskell In-Reply-To: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> References: <043.d09e0f4b0376ece5cf5c1c182fdd8b8e@haskell.org> Message-ID: <058.10693330c89a637781852db3fa6599cd@haskell.org> #13949: Haddock fails to typecheck an example with TemplateHaskell -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/should_compile/T13949 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3720 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * testcase: => th/should_compile/T13949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 21:07:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 21:07:27 -0000 Subject: [GHC] #8346: Rank 1 type signature still requires RankNTypes In-Reply-To: <049.38c02589d1bbe9e0e53bb31c4e45e3ed@haskell.org> References: <049.38c02589d1bbe9e0e53bb31c4e45e3ed@haskell.org> Message-ID: <064.987fd04677d0e87c113b89f540dbd9bf@haskell.org> #8346: Rank 1 type signature still requires RankNTypes -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #2605 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tom-bop): (A note to the reader: `RankNTypes` and `Rank2Types` are now the same) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 21:11:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 21:11:45 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.0bd8f2ef9bf51cb639ff094d36abc63c@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tom-bop): This may be related to #13960 (both have "Simplifier ticks exhausted") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 21:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 21:20:29 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.66f8f50db634b5a8acafcf8c9c03a36f@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): Thanks for reducing the test! I looked briefly at the 8.0.2 core-to-core output and it looks like we are seeing a great deal of simplification due to `bytestring`'s `Builder` mechanism. I also tested on 8.2.1 and it seems that the compiler is again able to simplify this program with the default ticks limit. That being said, we are still seeing a lot more builder things than I would expect in such a simple program, so I think a bit more investigation is in order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 21:34:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 21:34:17 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.defa7d8c3de0f1e1b3ead29718aed931@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): So it looks like the issue here is that `Query`'s `fromString` instance inlines: {{{ Inlining done: Database.PostgreSQL.Simple.Types.$fIsStringQuery_g Inlined fn: \ (x [Occ=Once] :: GHC.Base.String) -> let { cs :: Data.ByteString.Lazy.Internal.ByteString [LclId] cs = Data.ByteString.Builder.toLazyByteString (src src Data.ByteString.Builder.Prim.primMapListBounded @ GHC.Types.Char (src Data.ByteString.Builder.Prim.charUtf8) (src x)) } in src src Data.ByteString.Lazy.toStrict_goLen0 (src cs) cs }}} We then eventually inline `primMapListBounded`, which is itself a very large function. The simplifier is then force to crunch through all of this. The most surprising part of all of this is that in the end the `Builder` essentially iterates over the list produced by `unpackCString# "query"#` and painstakingly fills the target buffer byte-by-byte. Surely something has gone terribly wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 21:36:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 21:36:45 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.460f48fb555a34c2e77c66315f91ae36@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): Actually, looking a bit closer, it seems that we may need to encode byte- by-byte due to UTF-8 encoding. However, it doesn't seem to me like we should be inlining this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 22:10:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 22:10:03 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.122d318a8efa2b31f3f32b3b5d2de3fb@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12494.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by habibalamin): * differential: => Phab:D3726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 11 22:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Jul 2017 22:51:03 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.4a2fcc2b36db2e55d01210759f58df21@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 tom-bop): I've updated the repro case to not depend on the postgresql-simple library: Broken.hs: {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} module Broken (breaks) where import Data.ByteString import Data.ByteString.Builder import Data.ByteString.Lazy (toStrict) import Data.String (IsString(..)) newtype Query = Query ByteString toByteString :: Builder -> ByteString toByteString x = toStrict (toLazyByteString x) instance IsString Query where fromString = Query . toByteString . stringUtf8 breaks :: [(Query, Query)] breaks = [ ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") ] }}} broken.cabal: {{{ name: broken version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library exposed-modules: Broken other-extensions: OverloadedStrings build-depends: base , bytestring , bytestring-builder default-language: Haskell2010 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 02:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 02:31:19 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.495ef83976889978fddb99194fa7de9e@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): Thanks for digging into this further. My question is: where do the arguments to `mkVarSet` come from? Why don't they already have the kind variables in the lists? (They probably should!) My hunch is that the assertion failures you're seeing are genuine -- that is, they suggest real latent bugs. So, I propose this solution: keep digging! :) More concretely, point us to a small sampling (1 might be a suitable small number) of places where this `mkVarSet` call happens, and see if you can describe the context for where that list of variables comes from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 03:10:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 03:10:25 -0000 Subject: [GHC] #13955: Backpack does not handle unlifted types In-Reply-To: <049.a67534eef775638b6e13621c35886744@haskell.org> References: <049.a67534eef775638b6e13621c35886744@haskell.org> Message-ID: <064.ca035b1a8ad55f57c1d200ba13759e29@haskell.org> #13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: backpack | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: goldfire (added) @@ -101,0 +101,2 @@ + + It seems unlikely to sneak this into GHC 8.2 but who knows! New description: In the code snippet below, I attempt to use backpack with levity polymorphism: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} unit number-unknown where signature NumberUnknown where import GHC.Types data Number plus :: Number -> Number -> Number multiply :: Number -> Number -> Number module NumberStuff where import NumberUnknown funcA :: Number -> Number -> Number funcA x y = plus x (multiply x y) unit number-int where module NumberUnknown where type Number = Int plus :: Int -> Int -> Int plus = (+) multiply :: Int -> Int -> Int multiply = (*) unit number-unboxed-int where module NumberUnknown where import GHC.Prim type Number = Int# plus :: Int# -> Int# -> Int# plus = (+#) multiply :: Int# -> Int# -> Int# multiply = (*#) unit main where dependency number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] module Main where import NumberStuff main = putStrLn "Hello world!" }}} Compiling this with `ghc --backpack packer.bkp` fails with the following error: {{{ - Type constructor ‘Number’ has conflicting definitions in the module and its hsig file Main module: type Number = GHC.Prim.Int# :: TYPE 'GHC.Types.IntRep Hsig file: data Number The types have different kinds - while checking that number-unboxed-int:NumberUnknown implements signature NumberUnknown in number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] type Number = Int# }}} The error is pretty clear: `Number` can only be instantiated by types of kind `Type` (aka `TYPE LiftedRep`). Even while remaining levity monomorphic, there doesn't seem to be a way to pick a different kind. For example, redefining `Number` in the signature as {{{ data Number :: TYPE IntRep }}} leads to the following immediate failure: {{{ Kind signature on data type declaration has non-* return kind TYPE 'IntRep }}} I do not understand any of the internals of backpack, so I do not understand if there's anything fundamental that makes this impossible. Going one step further, I would like to be able to do something like this (the syntax here is not even currently valid for a backpack signature): {{{ type MyRep :: RuntimeRep data Number :: TYPE MyRep }}} This may be instantiated with something like this: {{{ type MyRep = IntRep type Number = Int# }}} And then end users would be able to monomorphize levity-polymorphic functions. This would be really neat because there is currently no way to do this in GHC. So, I guess there are really two feature requests in here. One is the ability to use unlifted data types with backpack. The other is the ability to use backpack to monomorphize levity-polymorphic functions. It seems unlikely to sneak this into GHC 8.2 but who knows! -- Comment: Here is a proof of concept patch which relaxes the "Kind signature on data type declaration has non-* return kind" check and fixes a bug (we're not currently renaming data type result kinds), which lets a modified version of the example work. Here's the patch: {{{ diff --git a/compiler/backpack/RnModIface.hs b/compiler/backpack/RnModIface.hs index 2e738c1ec6..b902b548a3 100644 --- a/compiler/backpack/RnModIface.hs +++ b/compiler/backpack/RnModIface.hs @@ -422,11 +422,13 @@ rnIfaceDecl d at IfaceData{} = do binders <- mapM rnIfaceTyConBinder (ifBinders d) ctxt <- mapM rnIfaceType (ifCtxt d) cons <- rnIfaceConDecls (ifCons d) + res_kind <- rnIfaceType (ifResKind d) parent <- rnIfaceTyConParent (ifParent d) return d { ifName = name , ifBinders = binders , ifCtxt = ctxt , ifCons = cons + , ifResKind = res_kind , ifParent = parent } rnIfaceDecl d at IfaceSynonym{} = do diff --git a/compiler/typecheck/TcHsType.hs b/compiler/typecheck/TcHsType.hs index 9b313f0c60..1ba2388ed5 100644 --- a/compiler/typecheck/TcHsType.hs +++ b/compiler/typecheck/TcHsType.hs @@ -1747,7 +1747,7 @@ tcDataKindSig :: Kind -> TcM ([TyConBinder], Kind) -- Returns the new TyVars, the extracted TyBinders, and the new, reduced -- result kind (which should always be Type or a synonym thereof) tcDataKindSig kind - = do { checkTc (isLiftedTypeKind res_kind) (badKindSig kind) + = do { return () -- checkTc (isLiftedTypeKind res_kind) (badKindSig kind) ; span <- getSrcSpanM ; us <- newUniqueSupply ; rdr_env <- getLocalRdrEnv diff --git a/compiler/iface/IfaceSyn.hs b/compiler/iface/IfaceSyn.hs index aadb7b5cad..0fd43eb228 100644 --- a/compiler/iface/IfaceSyn.hs +++ b/compiler/iface/IfaceSyn.hs @@ -691,18 +691,18 @@ pprIfaceDecl :: ShowSub -> IfaceDecl -> SDoc -- NB: pprIfaceDecl is also used for pretty-printing TyThings in GHCi -- See Note [Pretty-printing TyThings] in PprTyThing pprIfaceDecl ss (IfaceData { ifName = tycon, ifCType = ctype, - ifCtxt = context, + ifCtxt = context, ifResKind = kind, ifRoles = roles, ifCons = condecls, ifParent = parent, ifGadtSyntax = gadt, ifBinders = binders }) | gadt_style = vcat [ pp_roles - , pp_nd <+> pp_lhs <+> pp_where + , pp_nd <+> pp_lhs <+> dcolon <+> ppr kind <+> pp_where , nest 2 (vcat pp_cons) , nest 2 $ ppShowIface ss pp_extra ] | otherwise = vcat [ pp_roles - , hang (pp_nd <+> pp_lhs) 2 (add_bars pp_cons) + , hang (pp_nd <+> pp_lhs <+> dcolon <+> ppr kind) 2 (add_bars pp_cons) , nest 2 $ ppShowIface ss pp_extra ] where is_data_instance = isIfaceDataInstance parent }}} And the working example: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} unit number-unknown where signature NumberUnknown where import GHC.Types data Rep :: RuntimeRep data Number :: TYPE Rep plus :: Number -> Number -> Number multiply :: Number -> Number -> Number module NumberStuff where import NumberUnknown funcA :: Number -> Number -> Number funcA x y = plus x (multiply x y) unit number-int where module NumberUnknown where import GHC.Types type Rep = LiftedRep type Number = Int plus :: Int -> Int -> Int plus = (+) multiply :: Int -> Int -> Int multiply = (*) unit number-unboxed-int where module NumberUnknown where import GHC.Types import GHC.Prim type Rep = IntRep type Number = Int# plus :: Int# -> Int# -> Int# plus = (+#) multiply :: Int# -> Int# -> Int# multiply = (*#) unit main where dependency number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] module Main where import NumberStuff import GHC.Types main = print (I# (funcA 2# 3#)) }}} To turn this into a real patch, we have to construct an appropriate conditional for when to apply the `isLiftedTypeKind` test. Two main questions: 1. Is this sound for hs-boot? I don't think so: how can we know how to generate code of an unknown representation? We need to know the correct size to allocate for it. (Actually, this is a pretty interesting case where double-vision cures would solve the problem.) This means this should only be permitted for abstract data types in hsig files, and we probably still need to assert that it's some sort of TYPE thing. 2. Is `data F :: TYPE Rep` the syntax we want? It is a bit disingenous because, absented UnliftedDataTypes, the only way to actually implement one of these is with a type synonym. But it doesn't look that unnatural. We had a close miss when working on constraint synonyms (we ended up using `class A` to declare an abstract constraint rather than allowing `data F :: Constraint`. Pinging goldfire who may have opinions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 03:30:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 03:30:20 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.26d250b559cc39e218e7394e09c4e6b6@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * related: => #12791 Comment: Indeed, if I add `-fno-solve-constant-dicts` flag or turn off optimizations it compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 03:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 03:32:38 -0000 Subject: [GHC] #13961: TH.reify can be ambiguous when giving a name that's in multiple namespaces Message-ID: <050.c2b5ce566c4e4b676d32c8895857dd3b@haskell.org> #13961: TH.reify can be ambiguous when giving a name that's in multiple namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 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: -------------------------------------+------------------------------------- What should this program do? {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} module Bug where import Language.Haskell.TH (***) :: Bool -> Bool -> Bool (***) _ _ = True type (***) a b = Bool $(return []) main :: IO () main = putStrLn $(reify (mkName "***") >>= stringE . show) }}} The issue is that `reify (mkName "***")` could conceivable look up the `Info` of two different things: the value-level `(***)` or the type-level `(***)`. In this case, it happens to pick the value-level one: {{{ $ /opt/ghc/8.2.1/bin/runghc Bug.hs VarI Bug.*** (AppT (AppT ArrowT (ConT GHC.Types.Bool)) (AppT (AppT ArrowT (ConT GHC.Types.Bool)) (ConT GHC.Types.Bool))) Nothing }}} So if you want to look up the type-level `(***)`'s info in this way, you're hosed. If the above scenario seems contrived, and you find yourself thinking "but RyanGlScott, why don't you just use `'(***)` and `''(***)`?", keep in mind that there are times I need to look up //unqualified// names, and in those situations, `mkName` is all I have at my disposal for creating the `Name` to look up. There has to be a better way to go about business here. Perhaps we should introduce another function {{{#!hs reifyAll :: Name -> [Info] }}} That finds all possible `Info`s in all the namespaces the argument `Name` can be found in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 04:43:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 04:43:49 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.236c52d810f72baa26d0c6df9bbbc50a@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): OK, I have a guess about what's going on now. I didn't notice this before, because the shapes were similar, but there's a big difference between how 7.10 and 8.0 handle this code in the very earliest stages. In particular, `-ddump-ds` for 7.10 shows that `bool` has already inlined, exposing the `undefined`s (which it already knows to be bottom), whereas that has not happened in 8.0. Presumably, the slight optimization that takes place along with desugaring sees `bool = undefined`, concludes that there's no reason to have the extra identifier, and inlines it away altogether. In 8.0 and 8.2, `bool` is not just `undefined`, but `undefined` ''applied to a dictionary''. So suddenly it needs to actually produce a `bool` binding, and doesn't figure out until demand analysis that `bool` is always bottom. I suspect that what we want to do is to shift just a bit of demand analysis way up. `undefined` has demand signature {{{ x }}} So we really shouldn't need to wait for full demand analysis to conclude that `bool` has demand signature `x`; that follows immediately. Could we teach the ''simplifier'' how to reduce some demand applications? Perhaps it should even reduce any that it sees; I'm not sure of the full implications of that choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 04:46:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 04:46:43 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.c109f4a979f9204c62f32612569ab440@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 05:41:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 05:41:21 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.5e7d196064450a053eec8ae4bd3df2fb@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by LocutusOfBorg): * cc: costamagnagianfranco@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 06:09:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 06:09:11 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.12ee485bdd00c6aa2d3ebffef3201a14@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): Well looking at the definition of `mkVarSet`, it's no surprise that things are going awry: {{{#!hs mkVarSet :: [Var] -> VarSet mkVarSet = mkUniqSet mkUniqSet :: Uniquable a => [a] -> UniqSet a mkUniqSet = foldl' addOneToUniqSet emptyUniqSet }}} It's just grabbing the `Unique` of each type variable, and nothing more. Experimentally, when I tried a debugging build of GHC with the modified version of `substTyVar`, it fell over trying to compile `Data.Type.Equality`. I don't have the full assertion failure at the moment, but I recall that there were indeed more `tenvFVs` than what were contained in the `in_scope` set. [http://git.haskell.org/ghc.git/blob/1ee49cb11c7ad1af20c117a5395df96ded9a729f:/compiler/typecheck/TcGenDeriv.hs#l1686 Here's] a sample call to `mkVarSet` that's propagated through to `substTyVars`. This is used in the logic for `GeneralizedNewtypeDeriving`, where we need to take all the type variables mentioned in the instance head in preparation for the substitution that substitutes the class tyvars with the types used when deriving the instance. ...Although now that I think about it, this probably isn't a very good example of the thing we're worried about in this ticket, since that substitution is formed by simply zipping the class tyvars with their instantiated types in the instance, so there's no need to ever substitute in the kind of a tyvar... I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 13:43:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 13:43:16 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family Message-ID: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Taken from [http://ics.p.lodz.pl/~stolarek/_media/pl:research:promotion- haskell14-slides.pdf Promoting Functions to Type Families in Haskell] {{{#!hs {-# Language TypeFamilies, PolyKinds, DataKinds, TypeOperators #-} type family Map (f :: a -> b) (xs :: [a]) :: [b] where Map f '[] = '[] Map f (x ': xs) = f x ': Map f xs data N = O | S N type family Pred (n :: N) :: N where Pred O = O Pred (S n) = n -- The type family ‘Map’ should have 2 arguments, but has been given 1 type MapPred = Map Pred }}} fails as expected, but it works in GHCi {{{ ghci> :kind Map Pred Map Pred :: [N] -> [N] ghci> :kind! Map Pred '[S (S O), S O, O] Map Pred '[S (S O), S O, O] :: [N] = '['S 'O, 'O, 'O] }}} I can only test this in GHC 7.8, 8 now. I know GHCi has weird rules for unsaturated type families but I figured I'd write a ticket because the slides say "But it is invalid to write: `Map Pred '[O, S O]`". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 13:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 13:44:42 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.d84c74d242719e8803ec72eacc5d982e@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Taken from [http://ics.p.lodz.pl/~stolarek/_media/pl:research:promotion- > haskell14-slides.pdf Promoting Functions to Type Families in Haskell] > > {{{#!hs > {-# Language TypeFamilies, PolyKinds, DataKinds, TypeOperators #-} > > type family > Map (f :: a -> b) (xs :: [a]) :: [b] where > Map f '[] = '[] > Map f (x ': xs) = f x ': Map f xs > > data N = O | S N > > type family > Pred (n :: N) :: N where > Pred O = O > Pred (S n) = n > > -- The type family ‘Map’ should have 2 arguments, but has been given 1 > type MapPred = Map Pred > }}} > > fails as expected, but it works in GHCi > > {{{ > ghci> :kind Map Pred > Map Pred :: [N] -> [N] > ghci> :kind! Map Pred '[S (S O), S O, O] > Map Pred '[S (S O), S O, O] :: [N] > = '['S 'O, 'O, 'O] > }}} > > I can only test this in GHC 7.8, 8 now. I know GHCi has weird rules for > unsaturated type families but I figured I'd write a ticket because the > slides say "But it is invalid to write: `Map Pred '[O, S O]`". New description: Taken from [http://ics.p.lodz.pl/~stolarek/_media/pl:research:promotion- haskell14-slides.pdf Promoting Functions to Type Families in Haskell] {{{#!hs {-# Language TypeFamilies, PolyKinds, DataKinds, TypeOperators #-} type family Map (f :: a -> b) (xs :: [a]) :: [b] where Map f '[] = '[] Map f (x ': xs) = f x ': Map f xs data N = O | S N type family Pred (n :: N) :: N where Pred O = O Pred (S n) = n -- The type family ‘Map’ should have 2 arguments, but has been given 1 type MapPred = Map Pred }}} fails as expected, but commenting it out and writing `Map Pred` works in GHCi {{{ ghci> :kind Map Pred Map Pred :: [N] -> [N] ghci> :kind! Map Pred '[S (S O), S O, O] Map Pred '[S (S O), S O, O] :: [N] = '['S 'O, 'O, 'O] }}} I can only test this in GHC 7.8, 8 now. I know GHCi has weird rules for unsaturated type families but I figured I'd write a ticket because the slides say "But it is invalid to write: `Map Pred '[O, S O]`". -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 14:49:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 14:49:38 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.27b6e5a4678dbb9d841e65b7b7dd3af4@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Description changed by tom-bop: Old description: > **Update**: I've been able to provide a much simpler test case for this > error: > > Broken.hs: > > {{{ > #!haskell > {-# LANGUAGE OverloadedStrings #-} > > module Broken (breaks) where > > import Database.PostgreSQL.Simple.Types (Query) > > breaks :: [(Query, Query)] > breaks = [ > ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > , ("query", "query") > ] > }}} > > broken.cabal: > > {{{ > name: broken > version: 0.1.0.0 > build-type: Simple > cabal-version: >=1.10 > > library > exposed-modules: > Broken > other-extensions: > OverloadedStrings > build-depends: > base > -- >=4.9 && <4.10 > , postgresql-simple > -- >=0.5 && <0.6 > default-language: Haskell2010 > }}} > > `cabal install broken.cabal` results in: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone ord > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 20731 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > ---- > > ---- > > **Older info:** > > ~~This is unfortunately a closed-source codebase I'm experiencing this > with, but we get a GHC panic with a small/not-doing-anything-crazy > codebase:~~ > > {{{ > > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying RuleFired Class op return > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 118123 > > }}} > > When upping to `-fsimpl-tick-factor=150`, the error is a little > different: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone $ > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 177190 > }}} > > Upping to 200 makes the issue go away. > > We're building with > > `ghc-options: -fhpc` > > Before each build, we remove all .tix files and the .hpc directory > > At the point this error fires, we're compiling the 6th module of 9. The > first 6 modules to compile only have a total of 635 lines of code. > > To address issues I've seen in other similar tickets: > - There are no recursive module imports > - We don't use any `{-# INLINE #-}` or similar pragmas > - There is no Template Haskell other than a `makeLenses ''App` for a > small Snaplet. > - We don't have any "very"/exponentially recursive code > - We don't use any unboxed tuples (there *is* ST code in a module > that's compiled, but not the one ghc panics on) > - We don't use type families > - We don't use TypeRep or Typeable > - We don't use Generic > > When this error occurs, it fails on a module which has very little code > in it. It's mainly a list of ~200-300 Query[0] values, using > OverloadedStrings. I notice Query's `mappend`, which we use, is > `INLINE`d. > > Please let me know if I can provide more detail! > > [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs > /Database-PostgreSQL-Simple-Types.html#t:Query New description: **Update 2**: repro case with fewer dependencies: Broken.hs: {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} module Broken (breaks) where import Data.ByteString import Data.ByteString.Builder import Data.ByteString.Lazy (toStrict) import Data.String (IsString(..)) newtype Query = Query ByteString toByteString :: Builder -> ByteString toByteString x = toStrict (toLazyByteString x) instance IsString Query where fromString = Query . toByteString . stringUtf8 breaks :: [(Query, Query)] breaks = [ ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") ] }}} broken.cabal: {{{ name: broken version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library exposed-modules: Broken other-extensions: OverloadedStrings build-depends: base , bytestring , bytestring-builder default-language: Haskell2010 }}} Errors with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone pokeN_a1Db To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 22484 }}} ---- ---- **Update 1**: I've been able to provide a much simpler test case for this error: Broken.hs: {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} module Broken (breaks) where import Database.PostgreSQL.Simple.Types (Query) breaks :: [(Query, Query)] breaks = [ ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") , ("query", "query") ] }}} broken.cabal: {{{ name: broken version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library exposed-modules: Broken other-extensions: OverloadedStrings build-depends: base -- >=4.9 && <4.10 , postgresql-simple -- >=0.5 && <0.6 default-language: Haskell2010 }}} `cabal install broken.cabal` results in: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone ord To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 20731 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} ---- ---- **Older info:** ~~This is unfortunately a closed-source codebase I'm experiencing this with, but we get a GHC panic with a small/not-doing-anything-crazy codebase:~~ {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op return To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 118123 }}} When upping to `-fsimpl-tick-factor=150`, the error is a little different: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 177190 }}} Upping to 200 makes the issue go away. We're building with `ghc-options: -fhpc` Before each build, we remove all .tix files and the .hpc directory At the point this error fires, we're compiling the 6th module of 9. The first 6 modules to compile only have a total of 635 lines of code. To address issues I've seen in other similar tickets: - There are no recursive module imports - We don't use any `{-# INLINE #-}` or similar pragmas - There is no Template Haskell other than a `makeLenses ''App` for a small Snaplet. - We don't have any "very"/exponentially recursive code - We don't use any unboxed tuples (there *is* ST code in a module that's compiled, but not the one ghc panics on) - We don't use type families - We don't use TypeRep or Typeable - We don't use Generic When this error occurs, it fails on a module which has very little code in it. It's mainly a list of ~200-300 Query[0] values, using OverloadedStrings. I notice Query's `mappend`, which we use, is `INLINE`d. Please let me know if I can provide more detail! [0] http://hackage.haskell.org/package/postgresql-simple-0.5.3.0/docs /Database-PostgreSQL-Simple-Types.html#t:Query -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:15:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:15:07 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.aa7a974e8f99e188f8eeca064a1b8ec5@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tom-bop): * cc: tom-bop (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:24:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:24:00 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.c1ebac4a8f2c797dd0171d24ead27103@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott, goldfire (added) * keywords: => TypeFamilies * related: => #12089 Comment: Wow, that's astounding that it actually gives you the right answer... Richard, do you know how this is even working? Because I have to admit, this is shaking my faith in the belief that we need defunctionalization to partially apply type families ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:25:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:25:19 -0000 Subject: [GHC] #12089: :kind command allows unsaturated type family, In-Reply-To: <051.de4529f2a5c55440e217606da458c40d@haskell.org> References: <051.de4529f2a5c55440e217606da458c40d@haskell.org> Message-ID: <066.1b63726c12ccf752818812c0c3153a68@haskell.org> #12089: :kind command allows unsaturated type family, -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: => TypeFamilies * resolution: => duplicate * related: => #13962 Comment: Although this is the older ticket, I'll opt to close this in favor of #13962, since I find #13962 to be a cleaner example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:43:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:43:17 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.ea2073aaa8e6036f6a6bb0d141d59d3d@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): Thanks tom-bop! What is happening here is that GHC is inlining the guts of `toStrict (toLazyByteString x)` into each call site of `fromString` (since this is what `bytestring` requests). In the case that we are calling `fromString` on a dynamically computed `String` this might make sense since we could possibly fuse the encoding logic and buffer write into the producer. However, in this particular case the `String` is a literal (that is, produced by `unpackCString#`). I really don't think there is any good reason to inline here. Moreover, in principle `Builder` should handle string literals with a simple `memcpy`. Unfortunately, it can't currently do this (easily) since string literals don't have an exposed size and we treat `'\0'` a bit funnily (encoding it as `'\xC0\x80'`, which the `memcpy` would need to undo). Ultimately I think the right solution would be to simply treat literals properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:47:32 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.75f0a15969b326e73de6fc5b8aead26a@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11312 Comment: #11312 has previously suggested that we introduce a distinct `String#` primitive type (potentially with a fixed length). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:48:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:48:13 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.9771eecf96f3d67905230d26bb1c2d2d@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292, #5218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11292 => #11292, #5218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:48:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:48:24 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.1dc1994b570b08423ca0308d6a237373@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #5877 #10064 => #5877 #10064 #11312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 15:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 15:55:09 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.50522c38c31e15bbbd78bebe830560ec@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The "Simplifier ticks exhausted" message is a very general symptom; essentially it just means that the compiler has done more simplification work than it would have expected it would have needed to given the program size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 16:31:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 16:31:24 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 In-Reply-To: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> References: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> Message-ID: <058.6e506c28286ebceb09cabe841f5c08ed@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.2 Old description: > Compiling the package lame-0.1.1 using cabal, with profiling: > > [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, > dist/build/Codec/Audio/LAME.p_o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.0.20170704 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone lvl_soT9 > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 504681 > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in > ghc:SimplMonad > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > This is a regression; the package compiles fine with GHC 8.0.2 New description: Compiling the package lame-0.1.1 using cabal, with profiling: {{{ [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, dist/build/Codec/Audio/LAME.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_soT9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 504681 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a regression; the package compiles fine with GHC 8.0.2 -- Comment: Hmm, indeed this is quite bad: even a tick factor of 10000 doesn't finish (despite taking at least 10GB of memory before I killed it). It appears that it is looping on a set of inlinings. `-ddump-inlinings` says, {{{ ... Inlining done: Data.Text.$fEqText_$c== Inlining done: Codec.Audio.LAME.Internal.id3TagSetAlbumArt1 Inlining done: Codec.Audio.LAME.Internal.setBitrate1 Inlining done: Codec.Audio.LAME.Internal.setCompressionRatio1 Inlining done: Codec.Audio.LAME.Internal.id3TagSetAlbumArt1 Inlining done: Codec.Audio.LAME.Internal.setBitrate1 Inlining done: Codec.Audio.LAME.Internal.setCompressionRatio1 Inlining done: Codec.Audio.LAME.Internal.id3TagSetAlbumArt1 Inlining done: Codec.Audio.LAME.Internal.setBitrate1 Inlining done: Codec.Audio.LAME.Internal.setCompressionRatio1 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 17:26:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 17:26:51 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed Message-ID: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- 8.3.20170605: {{{ > :set -XRankNTypes -XTypeInType > import GHC.Exts (TYPE, RuntimeRep(LiftedRep)) > type Pair (a::TYPE rep) (b::TYPE rep') rep'' = forall (r::TYPE rep''). (a -> b -> r) -> r > :kind Pair Pair :: * -> * -> * > :kind Pair Int Pair Int :: * -> * > :kind Pair Int Float Pair Int Float :: * > :kind Pair Int Float LiftedRep Pair Int Float LiftedRep :: * }}} It still behaves oddly with `-fprint-explicit-runtime-reps` enabled {{{ > :set -fprint-explicit-runtime-reps > :kind Pair Pair :: * -> * -> forall (rep'' :: RuntimeRep) -> * > :kind Pair Int Pair Int :: * -> forall (rep'' :: RuntimeRep) -> * > :kind Pair Int Float Pair Int Float :: * > :kind Pair Int Float LiftedRep Pair Int Float LiftedRep :: * }}} I would have also expected to see `Pair`'s kind displayed something like this {{{#!hs forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> * }}} which is how the kind of the corresponding `newtype` gets displayed {{{ > newtype Pair2 (a::TYPE rep) (b::TYPE rep') rep'' = P2 (forall (r::TYPE rep''). (a -> b -> r) -> r) > :kind Pair2 Pair2 :: forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 17:30:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 17:30:14 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.745727ce26712e1c2a90f7688d9be546@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): For comparison here is the `newtype` `Pair2` becoming fully saturated {{{ > :kind Pair2 Pair2 :: forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> * > :kind Pair2 Int# Pair2 Int# :: * -> forall (rep'' :: RuntimeRep) -> * > :kind Pair2 Int# Double# Pair2 Int# Double# :: forall (rep'' :: RuntimeRep) -> * > :kind Pair2 Int# Double# LiftedRep Pair2 Int# Double# LiftedRep :: * }}} Is the kind of `Pair Int#` not `TYPE rep' -> forall (rep'' :: RuntimeRep) -> *` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 17:41:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 17:41:00 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.d43c354e6d9f3aedd69cbb7df0a1d824@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): > I'll assume by "it" you mean the thread-state save. I don't believe it is possible; afterall, there may be thread state (which may contain reference to heap objects) sitting in machine registers. Yes, i mean all the thread pause stuff. I want to understand what is the minimum preparation before we can make FFI calls which doesn't get in GC's way. I believe this helps to reduce GC pause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 18:12:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 18:12:08 -0000 Subject: [GHC] #13961: TH.reify can be ambiguous when giving a name that's in multiple namespaces In-Reply-To: <050.c2b5ce566c4e4b676d32c8895857dd3b@haskell.org> References: <050.c2b5ce566c4e4b676d32c8895857dd3b@haskell.org> Message-ID: <065.5213d3c48dd7e9a0dac6ce5844ebeb15@haskell.org> #13961: TH.reify can be ambiguous when giving a name that's in multiple namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Upon further thought, my needs are already addressed with the [http://hackage.haskell.org/package/template-haskell-2.11.1.0/docs /Language-Haskell-TH-Syntax.html#v:lookupValueName lookupValueName] and [http://hackage.haskell.org/package/template-haskell-2.11.1.0/docs /Language-Haskell-TH-Syntax.html#v:lookupTypeName lookupTypeName] functions, which allow me to search in particular namespaces. I now realize that the [http://hackage.haskell.org/package/template- haskell-2.11.1.0/docs/Language-Haskell-TH-Syntax.html#v:reify Haddocks for reify] even point this out - d'oh! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 18:50:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 18:50:02 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.d2297c909c01e7ae20028449119be7dc@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13311 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3678 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_fail/T13311 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 19:01:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 19:01:33 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.c36623cf92edf75395153bd68805a754@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): > Yes, i mean all the thread pause stuff. I want to understand what is the minimum preparation before we can make FFI calls which doesn't get in GC's way. I believe this helps to reduce GC pause. I don't believe there is anything that we do currently that can simply be omitted without careful consideration at very least. Have you confirmed that `safe` is really as slow as you think it is? I think that we should better characterise the problem before we begin discussing possible solutions. I think it would be helpful if you had a benchmark and could use it answer a few questions, a. What overhead is incurred by a `unsafe` call? b. What overhead is incurred by a `safe` call? c. Where specifically is the additional overhead of the `safe` call coming from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 19:18:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 19:18:41 -0000 Subject: [GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction Message-ID: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a file: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug (Boolean(F, TooGoodToBeTrue), catchAll) where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 -- catchAll TooGoodToBeTrue = 1 }}} If you compile this with `-Wall`, the warning will warn about `T`, not `TooGoodToBeTrue` (the other conlike in the `COMPLETE` set): {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -Wall Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘catchAll’: Patterns not matched: T | 15 | catchAll F = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Perhaps this isn't so bad, since it's intra-module. But the problem persists even across modules: {{{#!hs module Foo where import Bug catchAll2 :: Boolean -> Int catchAll2 F = 0 -- catchAll2 TooGoodToBeTrue = 1 }}} {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -c Bug.hs $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -c -Wall Foo.hs Foo.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘catchAll2’: Patterns not matched: Bug.T | 6 | catchAll2 F = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This one is really bad, since it's warning about `Bug.T`, which should be hidden! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 19:20:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 19:20:15 -0000 Subject: [GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction In-Reply-To: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> References: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> Message-ID: <065.87d28c6b66f56c64a24420d96d9d7db6@haskell.org> #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.0.1 => 8.2.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 19:22:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 19:22:40 -0000 Subject: [GHC] #13965: COMPLETE sets nerf redundant pattern-match warnings Message-ID: <050.35980eb4e29ad6aa872b8ca1767abfde@haskell.org> #13965: COMPLETE sets nerf redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I give redundant patterns for a datatype with a `COMPLETE` set, then GHC doesn't warn me at all. Here's an example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug (Boolean(F, TooGoodToBeTrue), catchAll) where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll F = 2 }}} GHC thinks this is fine and dandy: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -Wall GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, 1 module loaded. }}} This problem also persists across modules: {{{#!hs module Foo where import Bug catchAll2 :: Boolean -> Int catchAll2 F = 0 catchAll2 TooGoodToBeTrue = 1 catchAll2 F = 2 }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs -Wall GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 2] Compiling Bug ( Bug.hs, interpreted ) [2 of 2] Compiling Foo ( Foo.hs, interpreted ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 20:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 20:32:49 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.e7417269511b4dfbeb54203ae74108f2@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835, #13943 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * related: #5835 => #5835, #13943 Comment: It looks like this patch introduced a regression: #13943 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 20:44:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 20:44:30 -0000 Subject: [GHC] #13966: Missed optimization - loop fusion Message-ID: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> #13966: Missed optimization - loop fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc3 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 think GHC should be able to optimize func1 into func2, but currently it doesn't. {{{#!hs data Step s a = Done | Yield s a func1 high = loop1 0# 1# where loop1 acc i = case loop2 i of Done -> acc Yield (I# i') (I# x) -> loop1 (acc +# x) i' loop2 i = case tagToEnum# (i ># high) :: Bool of False -> case remInt# i 2# of 0# -> Yield (I# (i +# 1#)) (I# i) _ -> loop2 (i +# 1#) True -> Done func2 high = loop1 0# 1# where loop1 acc i = case tagToEnum# (i ># high) :: Bool of False -> case remInt# i 2# of 0# -> loop1 (acc +# i) (i +# 1#) _ -> loop1 acc (i +# 1#) True -> acc }}} When using the LLVM backend func2 is almost 4x faster than func1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 20:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 20:47:53 -0000 Subject: [GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals Message-ID: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | 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've tried to port Cabal's `Distribution.Simple.Build.PathsModule` from `String`s to `Data.ByteString.Builder`. The module uses lot's of string literals combined via `++`. After enabling `OverloadedStrings` and changing `++` to `Data.Semigroup.<>` I got an error message like in the subject. I have reproduced the issue on self-contained example, attached. ``` $ cd "/tmp/ghc-ticks-exhausted-bug/" && stack build test-0.1.0.0: configure (lib) Configuring test-0.1.0.0... test-0.1.0.0: build (lib) Preprocessing library test-0.1.0.0... [1 of 1] Compiling Test ( Test.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Test.o ) /tmp/ghc-ticks-exhausted-bug/Test.hs:17:21: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Linux’ /tmp/ghc-ticks-exhausted-bug/Test.hs:22:29: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Arm’ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 184333 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package test-0.1.0.0 using: /home/sergey/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:test --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 20:48:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 20:48:32 -0000 Subject: [GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals In-Reply-To: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> References: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> Message-ID: <059.0a27750fc9320c61e34d2989ae412b90@haskell.org> #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by sergv): * Attachment "ghc-ticks-exhausted-bug.tar.gz" added. Minimalistic cabal project that reproduces the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 20:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 20:49:46 -0000 Subject: [GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals In-Reply-To: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> References: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> Message-ID: <059.1ea41a877fd8b842616168c9a5c4e2c7@haskell.org> #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by sergv: Old description: > I've tried to port Cabal's `Distribution.Simple.Build.PathsModule` from > `String`s to `Data.ByteString.Builder`. The module uses lot's of string > literals combined via `++`. After enabling `OverloadedStrings` and > changing `++` to `Data.Semigroup.<>` I got an error message like in the > subject. > > I have reproduced the issue on self-contained example, attached. > > ``` > $ cd "/tmp/ghc-ticks-exhausted-bug/" && stack build > test-0.1.0.0: configure (lib) > Configuring test-0.1.0.0... > test-0.1.0.0: build (lib) > Preprocessing library test-0.1.0.0... > [1 of 1] Compiling Test ( Test.hs, .stack- > work/dist/x86_64-linux/Cabal-1.24.2.0/build/Test.o ) > > /tmp/ghc-ticks-exhausted-bug/Test.hs:17:21: warning: [-Wunused-top-binds] > Defined but not used: data constructor ‘Linux’ > > /tmp/ghc-ticks-exhausted-bug/Test.hs:22:29: warning: [-Wunused-top-binds] > Defined but not used: data constructor ‘Arm’ > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone $ > To increase the limit, use -fsimpl-tick-factor=N (default 100) > If you need to do this, let GHC HQ know, and what factor you needed > To see detailed counts use -ddump-simpl-stats > Total ticks: 184333 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > -- While building package test-0.1.0.0 using: > /home/sergey/.stack/setup-exe-cache/x86_64-linux/Cabal- > simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- > work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:test --ghc-options " > -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure 1 > > ``` New description: I've tried to port Cabal's `Distribution.Simple.Build.PathsModule` from `String`s to `Data.ByteString.Builder`. The module uses lot's of string literals combined via `++`. After enabling `OverloadedStrings` and changing `++` to `Data.Semigroup.<>` I got an error message like in the subject. I have reproduced the issue on self-contained example, attached. {{{ $ cd "/tmp/ghc-ticks-exhausted-bug/" && stack build test-0.1.0.0: configure (lib) Configuring test-0.1.0.0... test-0.1.0.0: build (lib) Preprocessing library test-0.1.0.0... [1 of 1] Compiling Test ( Test.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Test.o ) /tmp/ghc-ticks-exhausted-bug/Test.hs:17:21: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Linux’ /tmp/ghc-ticks-exhausted-bug/Test.hs:22:29: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Arm’ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 184333 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package test-0.1.0.0 using: /home/sergey/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:test --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 21:57:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 21:57:18 -0000 Subject: [GHC] #13968: TH gives "Illegal binding of built-in syntax" error Message-ID: <050.3732828496226ff6565e5d73754050f2@haskell.org> #13968: TH gives "Illegal binding of built-in syntax" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you try to splice in a definition that borrows an already existing `Name` using Template Haskell, GHC gives a confusing error message: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(pure [ValD (VarP 'succ) (NormalB (ConE 'True)) []]) }}} {{{ $ /opt/ghc/8.2.1/bin/runghc Bug.hs Bug.hs:6:3: error: Illegal binding of built-in syntax: succ | 6 | $(pure [ValD (VarP 'succ) (NormalB (ConE 'True)) []]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'm not exactly sure what should happen here. My hunch was that my spliced-in `succ` would shadow the `succ` that's already in-scope. But in any case, the error message you get currently is quite awful, so at the very least that should be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 12 23:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Jul 2017 23:35:51 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.5eee200a59c542943f6117a786322155@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): Here's a much more detailed stack trace when compiling `Data.Type.Equality`: {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -O2 -DDEBUG -dcore-lint Bug.hs [1 of 1] Compiling Data.Type.Equality ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170712 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {k1_X49O a_X49V b_X49X} tenv [X49T :-> k1_X49O, X49V :-> a_X49V, X49X :-> b_X49X] tenvFVs [X49M :-> k2_X49M, X49O :-> k1_X49O, X49V :-> a_X49V, X49X :-> b_X49X] cenv [] cenvFVs [] tys [*] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2198:44 in ghc:TyCoRep Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2198:44 in ghc:TyCoRep CallStack (from -prof): Panic.panic (compiler/utils/Panic.hs:(182,1)-(186,68)) Outputable.pprDebugAndThen (compiler/utils/Outputable.hs:(1191,1)-(1194,43)) ErrUtils.prettyPrintGhcErrors.\ (compiler/main/ErrUtils.hs:(658,23)-(666,44)) GhcMonad.gcatch.\.\ (compiler/main/GhcMonad.hs:117:46-63) Panic.throwGhcException (compiler/utils/Panic.hs:171:1-35) Panic.panicDoc (compiler/utils/Panic.hs:192:1-61) Outputable.pprPanic (compiler/utils/Outputable.hs:1137:1-49) Outputable.assertPprPanic (compiler/utils/Outputable.hs:(1185,1)-(1188,35)) TyCoRep.checkValidSubst (compiler/types/TyCoRep.hs:(2088,1)-(2113,57)) TyCoRep.substTy (compiler/types/TyCoRep.hs:(2120,1)-(2123,45)) Var.updateTyVarKind (compiler/basicTypes/Var.hs:456:1-64) TyCoRep.substTyVar (compiler/types/TyCoRep.hs:(2194,1)-(2198,61)) TyCoRep.subst_ty.go (compiler/types/TyCoRep.hs:(2176,5)-(2191,60)) TyCoRep.subst_ty (compiler/types/TyCoRep.hs:(2173,1)-(2191,60)) TyCoRep.subst_co.go_ty (compiler/types/TyCoRep.hs:2240:5-26) TyCoRep.subst_co.go (compiler/types/TyCoRep.hs:(2243,5)-(2264,66)) TyCoRep.subst_co (compiler/types/TyCoRep.hs:(2236,1)-(2270,36)) TyCoRep.substCoUnchecked (compiler/types/TyCoRep.hs:(2223,1)-(2225,33)) TyCoRep.substCoWithUnchecked (compiler/types/TyCoRep.hs:(2045,1)-(2047,41)) Coercion.mkInstCo (compiler/types/Coercion.hs:(950,1)-(952,31)) CoreOpt.pushCoTyArg.co2 (compiler/coreSyn/CoreOpt.hs:1012:5-62) CoreOpt.pushCoTyArg (compiler/coreSyn/CoreOpt.hs:(990,1)-(1012,62)) Simplify.simplCast.addCoerce (compiler/simplCore/Simplify.hs:(1427,8)-(1461,53)) Simplify.simplCast (compiler/simplCore/Simplify.hs:(1421,1)-(1461,53)) Simplify.rebuildCall (compiler/simplCore/Simplify.hs:(1761,1)-(1853,47)) Simplify.completeCall (compiler/simplCore/Simplify.hs:(1718,1)-(1749,60)) Simplify.simplIdF (compiler/simplCore/Simplify.hs:(1680,1)-(1712,53)) Simplify.simplExprC (compiler/simplCore/Simplify.hs:(1035,1)-(1041,42)) Simplify.simplExpr (compiler/simplCore/Simplify.hs:(1018,1)-(1026,45)) Simplify.simplLam (compiler/simplCore/Simplify.hs:(1501,1)-(1538,37)) Simplify.simplExprF1 (compiler/simplCore/Simplify.hs:(1064,1)-(1140,52)) Simplify.simplExprF (compiler/simplCore/Simplify.hs:(1049,1)-(1059,26)) Simplify.simplLazyBind (compiler/simplCore/Simplify.hs:(381,1)-(432,68)) Simplify.simplBind (compiler/simplCore/Simplify.hs:(362,1)-(368,58)) Simplify.simplRecOrTopPair.trace_bind (compiler/simplCore/Simplify.hs:(330,5)-(334,56)) Simplify.simplRecOrTopPair (compiler/simplCore/Simplify.hs:(321,1)-(334,56)) Simplify.simplTopBinds.simpl_bind (compiler/simplCore/Simplify.hs:(268,5)-(272,65)) Simplify.simplTopBinds.simpl_binds (compiler/simplCore/Simplify.hs:(264,5)-(266,64)) Simplify.simplTopBinds (compiler/simplCore/Simplify.hs:(248,1)-(272,65)) SimplCore.SimplTopBinds (compiler/simplCore/SimplCore.hs:758:29-64) SimplMonad.initSmpl (compiler/simplCore/SimplMonad.hs:(72,1)-(78,36)) SimplCore.simplifyPgmIO.do_iteration (compiler/simplCore/SimplCore.hs:(691,5)-(798,48)) SimplCore.simplifyPgmIO (compiler/simplCore/SimplCore.hs:(658,1)-(800,47)) IOEnv.liftIO (compiler/utils/IOEnv.hs:188:5-33) CoreMonad.liftIO (compiler/simplCore/CoreMonad.hs:615:5-37) CoreMonad.liftIOWithCount (compiler/simplCore/CoreMonad.hs:619:1-87) SimplCore.simplifyPgm (compiler/simplCore/SimplCore.hs:(644,1)-(649,48)) SimplCore.Simplify (compiler/simplCore/SimplCore.hs:456:40-55) SimplCore.doCorePass (compiler/simplCore/SimplCore.hs:(455,1)-(500,50)) SimplCore.runCorePasses.do_pass (compiler/simplCore/SimplCore.hs:(442,5)-(450,28)) SimplCore.runCorePasses (compiler/simplCore/SimplCore.hs:(439,1)-(452,24)) IOEnv.thenM.\ (compiler/utils/IOEnv.hs:(83,37)-(84,60)) IOEnv.thenM (compiler/utils/IOEnv.hs:(83,1)-(84,61)) CoreMonad.>>=.\ (compiler/simplCore/CoreMonad.hs:(524,30)-(528,38)) CoreMonad.>>= (compiler/simplCore/CoreMonad.hs:(524,5)-(528,38)) IOEnv.runIOEnv (compiler/utils/IOEnv.hs:127:1-30) CoreMonad.runCoreM (compiler/simplCore/CoreMonad.hs:(565,1)-(581,63)) SimplCore.core2core (compiler/simplCore/SimplCore.hs:(75,1)-(99,54)) HscTypes.liftIO.\ (compiler/main/HscTypes.hs:245:31-55) HscTypes.liftIO (compiler/main/HscTypes.hs:245:5-55) HscMain.Core2Core (compiler/main/HscMain.hs:1173:7-42) HscMain.hscSimplify' (compiler/main/HscMain.hs:(1170,1)-(1173,42)) HscMain.finish (compiler/main/HscMain.hs:(702,1)-(740,70)) HscTypes.>>=.\ (compiler/main/HscTypes.hs:(240,33)-(242,56)) HscTypes.>>= (compiler/main/HscTypes.hs:(240,5)-(242,56)) HscTypes.runHsc (compiler/main/HscTypes.hs:(251,1)-(254,12)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(644,1)-(690,60)) DriverPipeline.compileOne' (compiler/main/DriverPipeline.hs:(134,1)-(289,55)) GhcMake.upsweep_mod.compile_it_discard_iface (compiler/main/GhcMake.hs:(1436,13)-(1438,61)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1376,1)-(1532,49)) GhcMonad.liftIO (compiler/main/GhcMonad.hs:110:3-30) GhcMake.upsweep.upsweep' (compiler/main/GhcMake.hs:(1245,3)-(1344,91)) GhcMake.upsweep (compiler/main/GhcMake.hs:(1237,1)-(1344,91)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(389,9)-(390,41)) GhcMake.load' (compiler/main/GhcMake.hs:(242,1)-(490,38)) GhcMake.load (compiler/main/GhcMake.hs:(234,1)-(236,44)) Main.doMake (ghc/Main.hs:(695,1)-(720,13)) GhcMonad.gcatch.\ (compiler/main/GhcMonad.hs:117:19-63) GhcMonad.gcatch (compiler/main/GhcMonad.hs:(116,3)-(117,63)) ErrUtils.prettyPrintGhcErrors (compiler/main/ErrUtils.hs:(657,1)-(666,44)) Main.main' (ghc/Main.hs:(154,1)-(258,33)) GhcMonad.gmask.\.\.g_restore.\ (compiler/main/GhcMonad.hs:121:65-80) GhcMonad.gmask.\.\.g_restore (compiler/main/GhcMonad.hs:121:33-80) GhcMonad.gmask.\.\ (compiler/main/GhcMonad.hs:(120,30)-(123,53)) Exception.gmask.\ (compiler/utils/Exception.hs:64:27-29) Exception.gmask (compiler/utils/Exception.hs:64:3-30) GhcMonad.gmask.\ (compiler/main/GhcMonad.hs:(119,19)-(123,53)) GhcMonad.gmask (compiler/main/GhcMonad.hs:(118,3)-(123,53)) Exception.gfinally (compiler/utils/Exception.hs:(56,3)-(60,14)) GhcMonad.>>=.\ (compiler/main/GhcMonad.hs:107:26-57) GhcMonad.>>= (compiler/main/GhcMonad.hs:107:3-57) Panic.withSignalHandlers (compiler/utils/Panic.hs:(240,1)-(298,37)) GHC.runGhc (compiler/main/GHC.hs:(440,1)-(445,26)) Exception.gcatch (compiler/utils/Exception.hs:63:3-37) Exception.ghandle (compiler/utils/Exception.hs:73:1-21) GHC.defaultErrorHandler (compiler/main/GHC.hs:(380,1)-(412,7)) Main.main (ghc/Main.hs:(90,1)-(150,64)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 00:56:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 00:56:19 -0000 Subject: [GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals In-Reply-To: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> References: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> Message-ID: <059.6efa865dda9fae8b2464f4411413c11c@haskell.org> #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): This sounds eerily similar to #13960 which I diagnosed today. It looks like `bytestring`'s treatment of literals is quite silly, resulting in a great deal of inlining (and perhaps poor code). I have a patch in the works to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 04:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 04:18:16 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.56c4139220257f685688ce374e535f3e@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer Comment: I'll take a look and see if I can narrow it down to a module or two. A brief skim of the code didn't show anything too weird, so I'm guessing we're getting a lot of inlining or specialization from dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 05:11:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 05:11:00 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 In-Reply-To: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> References: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> Message-ID: <058.248e5e47b3a958210146aaf534e4d001@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): This appears to be due to, {{{ b8f58d79ee3e34840beeea2fab846a9f47bff21a is the first bad commit commit b8f58d79ee3e34840beeea2fab846a9f47bff21a Author: Simon Peyton Jones Date: Fri Dec 23 14:17:42 2016 +0000 Another improvement to SetLevels In my recent commit commit 432f952ef64641be9f32152a0fbf2b8496d8fe9c Float unboxed expressions by boxing I changed how float_me in lvlMFE worked. That was right, but it exposed another bug: an error expression wasn't getting floated as it should from a case alternative. And that led to a collection of minor improvements }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 10:02:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 10:02:15 -0000 Subject: [GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction In-Reply-To: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> References: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> Message-ID: <065.ce0bdef2ab9c9a787f850ec880e27c77@haskell.org> #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is nothing unique to `COMPLETE` pragmas, the exhaustiveness checker already breaks abstraction in this way. For example: {{{ module T (D(A)) where data D = A | B }}} {{{ module M where import T foo A = () }}} warns with {{{ M.hs:5:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: T.B | 5 | foo A = () | }}} and after all, to retain safety it has to. A function exported by `T` could mention `B` and then be used in `M`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 12:47:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 12:47:15 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 In-Reply-To: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> References: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> Message-ID: <058.c8415dd3c2660cb2275d000d8670a419@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): For future reference, the issue can be reproduced with `lame-0.1.1` with, {{{ ghc -dumpdir bad -fforce-recomp -dverbose-core2core -ddump-ds Codec/Audio/LAME -ddump-to-file -prof -fprof-auto-exported }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 12:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 12:59:27 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.777704c576d321a14d97bed0c16bb632@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): comment:3 is easy to diagnose: note that the stack includes `substCoWithUnchecked`, but the "uncheckedness" doesn't propagate. Not sure what the best way to fix this is, but the underlying problem is not ours. comment:2 is as you describe: the `inst_tvs` here do ''not'' need to contain the kinds. But the `InScopeSet` surely does! Use `closeOverKinds`. This is a latent bug, as I expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 13:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 13:42:12 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.d10706748086abee671a2f9db7aa2b35@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The problem is that we are repeatedly able to solves constraints of the form `Take (k - 1)` with the dictionary we have for `Take n` which matches any constraint. We loop forever as we track whether we have previously solved precisely the same constraint rather than used the same dictionary before. I am not sure exactly how best to fix this. This code does use `UndecidableInstances` so it is perhaps not entirely our responsibility to ensure termination but it has not yet been ruled how this flag should interact with `UndecidableInstances`. As an aside, you can also write your program like this which avoids overlapping and undecidable instances by making the recursion clear from the types but admittedly, it is not very convenient to write numbers like this. {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} module Data.List.Unrolled where import GHC.TypeLits data N = Z | S N -- | Drop @n@ elements from a list class Drop (n :: N) where drop :: [a] -> [a] instance Drop Z where drop xs = xs {-# INLINE drop #-} instance (Drop n) => Drop (S n) where drop [] = [] drop (_ : xs) = drop @n xs {-# INLINE drop #-} -- | Take @n@ elements from a list class Take (n :: N) where take :: [a] -> [a] instance Take Z where take _ = [] {-# INLINE take #-} instance (Take n) => Take (S n) where take [] = [] take (x : xs) = x : take @n xs {-# INLINE take #-} -- | Split list at @n at -th element. splitAt :: forall (n :: N) a. (Take n, Drop n) => [a] -> ([a], [a]) splitAt xs = (take @n xs, drop @n xs) -- | Split list into chunks of the given length @c at . @n@ is length of the list. class ChunksOf (n :: N) (c :: N) where chunksOf :: [a] -> [[a]] instance ChunksOf Z c where chunksOf _ = [] {-# INLINE chunksOf #-} instance (Take c, Drop c, ChunksOf n c) => ChunksOf (S n) c where chunksOf xs = let (l, r) = splitAt @c xs in l : chunksOf @n @c r {-# INLINE chunksOf #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 14:40:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 14:40:37 -0000 Subject: [GHC] #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable Message-ID: <051.4d09009f5fc2200c9a02cbee32d63d51@haskell.org> #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I only have access to an older version (GHC 8.0.1), this may have been fixed. If I define {{{#!hs {-# language PatternSynonyms #-} pattern R{aaa} = uuu }}} it complains about a recursive pattern synonym {{{ $ ghci-8.0.1 -ignore-dot-ghci /tmp/tmp.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tmp.hs, interpreted ) /tmp/tmp.hs:1:1: error: Recursive pattern synonym definition with following bindings: R (defined at /tmp/tmp.hs:3:1-22) Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 14:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 14:50:15 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.9681acd6915c37eb3bc1143bdaef7fa7@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * cc: dan@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 15:12:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 15:12:35 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.1a3100fbf1784c63ec1048fddc9e5935@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 andrewthad): I've open a PR that adds docs explaining this behavior. https://github.com/ghc/ghc/pull/51 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 15:20:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 15:20:00 -0000 Subject: [GHC] #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable In-Reply-To: <051.4d09009f5fc2200c9a02cbee32d63d51@haskell.org> References: <051.4d09009f5fc2200c9a02cbee32d63d51@haskell.org> Message-ID: <066.6a7820d1cc444bb7c51a101c262b3cf2@haskell.org> #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: It's fixed in GHC HEAD (probably by #13470): {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:3:11: error: Not in scope: ‘aaa’ | 3 | pattern R{aaa} = uuu | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 15:25:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 15:25:22 -0000 Subject: [GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction In-Reply-To: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> References: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> Message-ID: <065.981feb59a060ec0015eb63a2c9a604a8@haskell.org> #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Perhaps I'm fundamentally misunderstanding something about `COMPLETE` sets, but this doesn't feel like a very satisfying explanation. My intuition is that specifying a `COMPLETE` set for a data type is tantamount to overriding the pattern match exhaustiveness checker's behavior w.r.t. to that particular data type, and as such, I would any warnings that are emitted under the `-Wincomplete-patterns` label to be adjusted according to whatever `COMPLETE` sets are in scope. For example, in my original example, I would simply expect that in this warning: {{{ Foo.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘catchAll2’: Patterns not matched: Bug.T }}} It would warn about `TooGoodToBeTrue`, not `Bug.T`. That's all. Replying to [comment:2 mpickering]: > This is nothing unique to `COMPLETE` pragmas, the exhaustiveness checker already breaks abstraction in this way. > > For example: > > {{{ > module T (D(A)) where > > data D = A | B > }}} > > {{{ > module M where > > import T > > foo A = () > }}} > > warns with > > {{{ > M.hs:5:1: warning: [-Wincomplete-patterns] > Pattern match(es) are non-exhaustive > In an equation for ‘foo’: Patterns not matched: T.B > | > 5 | foo A = () > | > }}} That seems fine to me, since the user didn't specify `{-# COMPLETE A #-}` for the data type `D`. If she did, I wouldn't expect a warning for `foo`. > and after all, to retain safety it has to. A function exported by `T` could mention `B` and then be used in `M`. I don't understand what you mean. A function exported from `T` surely doesn't have any effect on whether a function defined in `M` is exhaustive, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 16:23:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 16:23:05 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused Message-ID: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1-rc3 System | 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: -------------------------------------+------------------------------------- A multithreaded program generated by latest release candidate occasionally segfaults inside the runtime system. It is always at the same instruction: {{{ (gdb) bt #0 0x00007f25ca77fde3 in threadPaused () from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr- ghc8.2.0.20170704.so #1 0x00007f25ca795068 in stg_returnToSched () from /nix/store/995xifyvjlbvd138r0gpq008nyxls6hr- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr- ghc8.2.0.20170704.so #2 0x0000000000000000 in ?? () (gdb) disassemble Dump of assembler code for function threadPaused: 0x00007f25ca77fda0 <+0>: push %r15 0x00007f25ca77fda2 <+2>: push %r14 0x00007f25ca77fda4 <+4>: push %r13 0x00007f25ca77fda6 <+6>: push %r12 0x00007f25ca77fda8 <+8>: mov %rdi,%r12 0x00007f25ca77fdab <+11>: push %rbp 0x00007f25ca77fdac <+12>: push %rbx 0x00007f25ca77fdad <+13>: mov %rsi,%rbp 0x00007f25ca77fdb0 <+16>: sub $0x28,%rsp 0x00007f25ca77fdb4 <+20>: callq 0x7f25ca77a640 0x00007f25ca77fdb9 <+25>: cmpw $0x3,0x20(%rbp) 0x00007f25ca77fdbe <+30>: je 0x7f25ca77fe1d 0x00007f25ca77fdc0 <+32>: mov 0x18(%rbp),%rax 0x00007f25ca77fdc4 <+36>: mov 0x8(%rax),%edx 0x00007f25ca77fdc7 <+39>: mov 0x10(%rax),%rbx 0x00007f25ca77fdcb <+43>: lea 0x18(%rax,%rdx,8),%r13 0x00007f25ca77fdd0 <+48>: cmp %rbx,%r13 0x00007f25ca77fdd3 <+51>: jbe 0x7f25ca77fe16 0x00007f25ca77fdd5 <+53>: xor %r9d,%r9d 0x00007f25ca77fdd8 <+56>: xor %r14d,%r14d 0x00007f25ca77fddb <+59>: xor %r15d,%r15d 0x00007f25ca77fdde <+62>: xor %ecx,%ecx 0x00007f25ca77fde0 <+64>: mov (%rbx),%rdx => 0x00007f25ca77fde3 <+67>: mov -0x8(%rdx),%eax 0x00007f25ca77fde6 <+70>: cmp $0x21,%eax 0x00007f25ca77fde9 <+73>: je 0x7f25ca77ff10 0x00007f25ca77fdef <+79>: jb 0x7f25ca77fed0 0x00007f25ca77fdf5 <+85>: lea -0x23(%rax),%esi 0x00007f25ca77fdf8 <+88>: cmp $0x1,%esi 0x00007f25ca77fdfb <+91>: ja 0x7f25ca77fed0 0x00007f25ca77fe01 <+97>: cmp $0x8,%r15d 0x00007f25ca77fe05 <+101>: setbe %dl 0x00007f25ca77fe08 <+104>: test %ecx,%ecx 0x00007f25ca77fe0a <+106>: setne %al 0x00007f25ca77fe0d <+109>: test %al,%dl 0x00007f25ca77fe0f <+111>: jne 0x7f25ca77fe30 0x00007f25ca77fe11 <+113>: cmp %r15d,%ecx 0x00007f25ca77fe14 <+116>: ja 0x7f25ca77fe30 0x00007f25ca77fe16 <+118>: andl $0xffffff7f,0x24(%rbp) 0x00007f25ca77fe1d <+125>: add $0x28,%rsp 0x00007f25ca77fe21 <+129>: pop %rbx 0x00007f25ca77fe22 <+130>: pop %rbp 0x00007f25ca77fe23 <+131>: pop %r12 0x00007f25ca77fe25 <+133>: pop %r13 0x00007f25ca77fe27 <+135>: pop %r14 0x00007f25ca77fe29 <+137>: pop %r15 0x00007f25ca77fe2b <+139>: retq 0x00007f25ca77fe2c <+140>: nopl 0x0(%rax) 0x00007f25ca77fe30 <+144>: lea 0x3e2c9(%rip),%rax # 0x7f25ca7be100 0x00007f25ca77fe37 <+151>: cmpb $0x0,0x4c(%rax) 0x00007f25ca77fe3b <+155>: je 0x7f25ca77fe16 0x00007f25ca77fe3d <+157>: mov 0x18(%rbp),%rax 0x00007f25ca77fe41 <+161>: mov 0x10(%rax),%r14 0x00007f25ca77fe45 <+165>: cmp %rbx,%r14 0x00007f25ca77fe48 <+168>: lea -0x10(%r14),%r13 0x00007f25ca77fe4c <+172>: ja 0x7f25ca780082 0x00007f25ca77fe52 <+178>: xor %ecx,%ecx 0x00007f25ca77fe54 <+180>: jmp 0x7f25ca77fe70 0x00007f25ca77fe56 <+182>: nopw %cs:0x0(%rax,%rax,1) 0x00007f25ca77fe60 <+192>: add $0x1,%ecx 0x00007f25ca77fe63 <+195>: add $0x10,%r14 0x00007f25ca77fe67 <+199>: cmp %rbx,%r14 0x00007f25ca77fe6a <+202>: ja 0x7f25ca780060 0x00007f25ca77fe70 <+208>: mov (%r14),%rdx 0x00007f25ca77fe73 <+211>: mov -0x8(%rdx),%eax 0x00007f25ca77fe76 <+214>: cmp $0x21,%eax 0x00007f25ca77fe79 <+217>: je 0x7f25ca77fe60 0x00007f25ca77fe7b <+219>: cmp $0x1,%ecx 0x00007f25ca77fe7e <+222>: jbe 0x7f25ca77fe9b 0x00007f25ca77fe80 <+224>: lea -0x10(%r14),%rdx 0x00007f25ca77fe84 <+228>: mov %r13,%r8 0x00007f25ca77fe87 <+231>: mov %rbp,%rsi 0x00007f25ca77fe8a <+234>: mov %r12,%rdi 0x00007f25ca77fe8d <+237>: callq 0x7f25ca77fce0 0x00007f25ca77fe92 <+242>: mov (%r14),%rdx 0x00007f25ca77fe95 <+245>: mov %rax,%r13 0x00007f25ca77fe98 <+248>: mov -0x8(%rdx),%eax 0x00007f25ca77fe9b <+251>: cmp $0x1f,%eax 0x00007f25ca77fe9e <+254>: je 0x7f25ca780048 0x00007f25ca77fea4 <+260>: cmp $0x20,%eax 0x00007f25ca77fea7 <+263>: je 0x7f25ca780038 0x00007f25ca77fead <+269>: cmp $0x1d,%eax 0x00007f25ca77feb0 <+272>: je 0x7f25ca780020 ... }}} Which I believe is the same place as reported in #9130. Apart from this error, the program also crashes, occasionally, with: {{{ sigym4-propag: internal error: scavenge_stack: weird activation record found on stack: -1717986919 (GHC version 8.2.0.20170704 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (The activation record number changes between runs). I believe these to be related since I've found (after a long git-bisect session) that they both began manifesting themselves after the same GHC commit: c1c0985416a6f9766c03d361449f556905bf8e1d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 16:26:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 16:26:51 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.4cbbd6f6f13c29ac0d33931c6e90ff06@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): I don't suppose you could provide a reproducer for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 16:45:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 16:45:29 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.85eda1a4930dae37b2efd9dab68bea55@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): What might also help is if you could compile your program with `-debug` and paste the output of `x/64a tso->stackobj->sp` after the program crashes. It seems like we are getting confused walking the stack, so it would be interesting to know what the stack looks like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 16:51:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 16:51:33 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.b0d17aad1c7532d378758105ae0ad0fe@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:2 bgamari]: > What might also help is if you could compile your program with `-debug` and paste the output of `x/64a tso->stackobj->sp` after the program crashes. It seems like we are getting confused walking the stack, so it would be interesting to know what the stack looks like. I did but I still had no symbols in gdb. I must be striping them somewhere in my build... I will take a look and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:00:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:00:38 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.8ea2abb0e8cd892a9e7cd9e1177380bc@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:1 bgamari]: > I don't suppose you could provide a reproducer for this? It's hard for me to provide a reproducible example since it is in a complex proprietary program and I have of what could be causing this besides that increasing the number of capabilities with -N tends to increase the frequency of the crashes. I might be able to convince my employer to opensource the "engine" (a 2D spread simulation, which we use to simulate wildfires). I will certainly try to use this ticket as an argument in favor of doing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:04:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:04:29 -0000 Subject: [GHC] #13971: Misleading "Kind mis-match on LHS of default declaration" error Message-ID: <050.d40bc20f28df73e49993d6ba5839a725@haskell.org> #13971: Misleading "Kind mis-match on LHS of default declaration" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails to typecheck, unsurprisingly: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a :: k type T a = Int }}} But the error message it gives threw me for a loop initially: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:3: error: • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ | 7 | type T a = Int | ^^^^^^^^^^^^^^ Failed, 0 modules loaded. }}} The LHS of the default declaration is perfectly fine - the real source of the error is the RHS! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:06:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:06:21 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.346a9b7858ceea6ef018ac518fd32647@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): Note that I believe `Cabal` strips by default`. > It's hard for me to provide a reproducible example since it is in a complex proprietary program and I have of what could be causing this besides that increasing the number of capabilities with -N tends to increase the frequency of the crashes. Quite understandable. Anything you can offer would be very much appreciated. I tested this patch with the testcase from #13615 with over a day of runtime without seeing this crash, so it seems that you are tickling something odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:31:19 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.f9ab9cfdc5a6b2145b33863a738ec16f@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): If you aren't able to get debug symbols, I believe that the `StgTSO*` argument can be found at `*$rbp`. Consequently, `x/64a ((uint64_t*) $rbp)[0] + 0x10` will likely do the trick. For my future reference: `$rbx` contains `frame`, `$r13` contains `stack_end` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:35:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:35:43 -0000 Subject: [GHC] #13972: GHC 8.2 error message around indexes for associated type instances is baffling Message-ID: <050.88741f04ace45b35af0a1d7cc48d28bc@haskell.org> #13972: GHC 8.2 error message around indexes for associated type instances is baffling -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program doesn't typecheck (only in GHC 8.2 and later): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: k) where type T k :: Type instance C Left where type T (a -> Either a b) = Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:8: error: • Type indexes must match class instance head Expected: T (a -> Either a b) Actual: T (a -> Either a b) • In the type instance declaration for ‘T’ In the instance declaration for ‘C Left’ | 12 | type T (a -> Either a b) = Int | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Well those expected and actual types look pretty darn similar to me! Note that the problem can be worked around by giving an explicit kind annotation for `Left`: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: k) where type T k :: Type instance C (Left :: a -> Either a b) where type T (a -> Either a b) = Int }}} I see two things we could do here: 1. Relax the "Type indexes must match class instance head" check so that it doesn't apply to invisible kind variables like `a` and `b`. 2. Clarify the error message. At the very least, we could say `Expected: T (a1 -> Either a1 b1)` as a hint that `a` and `b` aren't the same type variables as `a1` and `b1`. In an ideal world, we'd even indicate where `a1` and `b1` should be coming from (the kind of `Left`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 17:45:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 17:45:09 -0000 Subject: [GHC] #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable In-Reply-To: <051.4d09009f5fc2200c9a02cbee32d63d51@haskell.org> References: <051.4d09009f5fc2200c9a02cbee32d63d51@haskell.org> Message-ID: <066.e1a21c9c3218a0355f8a5c4bcac6bca3@haskell.org> #13969: Record pattern synonym incorrectly claims it's recursive, given unbound variable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thanks for verifying! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 19:43:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 19:43:00 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.fa5ce60b8b4e322029193fa1ad98a0cc@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): mpickering, would this be fixed by preventing this mechanism from selecting overlappable instances? If so, maybe we should require an overlap pragma for any instance that will be overlapped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 19:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 19:44:02 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.b90285dcf4e777f1e5487ab0b94d7035@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:07:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:07:13 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.0e18c8d9f4ad29f34cde282e88f784af@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"f656fba19d0cefe05643ddea35d080ea332a6584/ghc" f656fba1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f656fba19d0cefe05643ddea35d080ea332a6584" [skip ci] Temporarily disable split-sections on Windows. Summary: This temporarily disabled split-sections again on Windows because of the overhead in linking it introduces. Unfortunately because BFD is so slow a testsuite run gets almost 2x slower. Simply linking Hello World takes an unacceptable long time. So for now, it'll be disabled as we look into different linkers such as LLD. Test Plan: ./validate Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3731 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:08:40 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.d9c8ea52046bb89a09982e77874fd265@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: closed => new * resolution: fixed => Comment: Need to investigate using lld instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:21:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:21:35 -0000 Subject: [GHC] #13973: NamedFieldPuns fails for qualified imports if field name is already in scope Message-ID: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> #13973: NamedFieldPuns fails for qualified imports if field name is already in scope -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Hi, I get following error on the program below {{{ Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring test-0.1.0.0... Building test-0.1.0.0... Preprocessing library test-0.1.0.0... [1 of 2] Compiling Record ( Record.hs, dist/build/Record.o ) [2 of 2] Compiling Test ( Test.hs, dist/build/Test.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The cabal project: {{{ name: test version: 0.1.0.0 cabal-version: >= 1.16 build-type: Simple library exposed-modules: Record Test default-language: Haskell98 build-depends: base >= 4.7 }}} The module `Record.hs`: {{{#!hs module Record (Record(..)) where data Record = Record { field1 :: Int, field2 :: Int } }}} The main module `Test.hs`: {{{#!hs {-# LANGUAGE NamedFieldPuns #-} module Test (foo) where import qualified Record as Rec -- The culprit field2 :: () field2 = () foo :: Rec.Record -> Int foo Rec.Record{Rec.field1, field2} = field1 + field2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:21:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:21:56 -0000 Subject: [GHC] #13973: NamedFieldPuns fails for qualified imports if field name is already in scope In-Reply-To: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> References: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> Message-ID: <059.896a20a85eb4e742cea3a86c21ac6220@haskell.org> #13973: NamedFieldPuns fails for qualified imports if field name is already in scope -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by sergv): * Attachment "named-field-puns-panic.tar.gz" added. Minimalistic cabal project that reproduces the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:24:14 -0000 Subject: [GHC] #13973: NamedFieldPuns fails for qualified imports if field name is already in scope In-Reply-To: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> References: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> Message-ID: <059.d66ec5898f209721b576d4143591ba02@haskell.org> #13973: NamedFieldPuns fails for qualified imports if field name is already in scope -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sergv): * failure: Compile-time crash or panic => Poor/confusing error message Old description: > Hi, I get following error on the program below > > {{{ > Package has never been configured. Configuring with default flags. If > this > fails, please run configure manually. > Resolving dependencies... > Configuring test-0.1.0.0... > Building test-0.1.0.0... > Preprocessing library test-0.1.0.0... > [1 of 2] Compiling Record ( Record.hs, dist/build/Record.o ) > [2 of 2] Compiling Test ( Test.hs, dist/build/Test.o ) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > translateConPatVec: lookup > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > The cabal project: > {{{ > name: test > version: 0.1.0.0 > cabal-version: >= 1.16 > build-type: Simple > > library > exposed-modules: Record Test > default-language: Haskell98 > build-depends: base >= 4.7 > }}} > > The module `Record.hs`: > {{{#!hs > module Record (Record(..)) where > > data Record = Record { field1 :: Int, field2 :: Int } > }}} > > The main module `Test.hs`: > {{{#!hs > {-# LANGUAGE NamedFieldPuns #-} > > module Test (foo) where > > import qualified Record as Rec > > -- The culprit > field2 :: () > field2 = () > > foo :: Rec.Record -> Int > foo Rec.Record{Rec.field1, field2} = field1 + field2 > }}} New description: Hi, I get following error on the program below {{{ Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring test-0.1.0.0... Building test-0.1.0.0... Preprocessing library test-0.1.0.0... [1 of 2] Compiling Record ( Record.hs, dist/build/Record.o ) [2 of 2] Compiling Test ( Test.hs, dist/build/Test.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The cabal project: {{{ name: test version: 0.1.0.0 cabal-version: >= 1.16 build-type: Simple library exposed-modules: Record Test default-language: Haskell98 build-depends: base >= 4.7 }}} The module `Record.hs`: {{{#!hs module Record (Record(..)) where data Record = Record { field1 :: Int, field2 :: Int } }}} The main module `Test.hs`: {{{#!hs {-# LANGUAGE NamedFieldPuns #-} module Test (foo) where import qualified Record as Rec -- The culprit field2 :: () field2 = () foo :: Rec.Record -> Int foo Rec.Record{Rec.field1, field2} = field1 + field2 }}} The program is invalid - named field `field2` should be written as `Rec.field2`, however I'd expect more informative error message instead of panic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:28:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:28:31 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.48648e840ed9e42396ad455072e9e452@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:2 bgamari]: > What might also help is if you could compile your program with `-debug` and paste the output of `x/64a tso->stackobj->sp` after the program crashes. It seems like we are getting confused walking the stack, so it would be interesting to know what the stack looks like. I finally managed to get debugging symbols. I had to pass {{{dontStrip = true}}} to the Nix derivation that builds ghc from git. Anyway, it crashed again at the same point and here's what gdb says: {{{ (gdb) x/64a tso->stackobj->sp 0x421cdbfea8: 0x7f9b3d2cc5c8 0x420c746c00 0x421cdbfeb8: 0x100 0x4204442df9 0x421cdbfec8: 0xf4 0xfffffffffffffff4 0x421cdbfed8: 0x7f9b3d2cce88 0x420c746c00 0x421cdbfee8: 0x7f9b4367b308 0x6465c88fdad5932f 0x421cdbfef8: 0xffffffffffffffff 0x6 0x421cdbff08: 0x0 0x7f9b4367be08 0x421cdbff18: 0x42042655c8 0x42042655e0 0x421cdbff28: 0x4202361568 0x7f9b3d2cce88 0x421cdbff38: 0x4204442dc8 0x7f9b436ac7b0 0x421cdbff48: 0x63b 0xffffffffffffffe4 0x421cdbff58: 0x420447bb61 0x7f9b441837a0 0x421cdbff68: 0x42187a9841 0x420447bb71 0x421cdbff78: 0xfffffffffffffff4 0x4204265518 0x421cdbff88: 0x42183d5c09 0x42183f1523 0x421cdbff98: 0x626 0x42187a0119 0x421cdbffa8: 0x7f9b3d2c8588 0x7f9b3dbf2cc0 0x421cdbffb8: 0x7f9b3d2c8ae8 0xc 0x421cdbffc8: 0x7f9b3e119592 0x7f9b3dbf2d80 0x421cdbffd8: 0x42183f155a 0x7f9b3d2c8ae8 0x421cdbffe8: 0xc 0x7f9b3e14ee2a 0x421cdbfff8: 0x7f9b3d2c8088 0x7f9b41aa3340 0x421cdc0008: 0x421cdc00d1 0x421cdc00c1 0x421cdc0018: 0x7f9b41aa3340 0x421cdc00f1 0x421cdc0028: 0x421cdc00e1 0x7f9b41aa3340 0x421cdc0038: 0x421cdc0111 0x421cdc0101 0x421cdc0048: 0x7f9b41aa3340 0x421cdc0131 0x421cdc0058: 0x421cdc0121 0x7f9b41aa3340 0x421cdc0068: 0x421cdc0151 0x421cdc0141 0x421cdc0078: 0x7f9b41aa3340 0x421cdc0171 0x421cdc0088: 0x421cdc0161 0x7f9b41aa3340 0x421cdc0098: 0x421cdc0191 0x421cdc0181 }}} BTW, I've got an approval to factor out the spread algorithm from our program as an opensource library so I'll begin working on that tomorrow. Hopefully the bug still manifests itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:31:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:31:32 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.bc6795b89a854317ba46ea3db9b0b5a1@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Now that I have debugging symbols I can confirm that the segfault occurs in the {{{switch(info->i.type}}} line (224) reported in #9130 {{{ (gdb) bt #0 threadPaused (cap=0xc38ef0, tso=0x421dcc50f0) at rts/ThreadPaused.c:224 #1 0x00007f9b3d2c8275 in stg_returnToSched () from /nix/store/f46shfdh7qmagqw11w61g099jm544fd4-ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts /libHSrts_thr_debug-ghc8.2.0.20170704.so #2 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:39:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:39:59 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 Message-ID: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The official distribution of GHC for FreeBSD, as retrieved from [0] attempts to link against libutil.so.8 FreeBSD 10.3 is actually built against libutil.so.9, and there is no /lib/libutil.so.8 (and no version 8 of the library available via the package manager/ports). Symlinking /lib/libutil.so.9 to /lib/libutil.so.8 appears to allow GHC to run without issue, but I can't guarantee the results. Since the distributed GHC tarball is specific to FreeBSD 10.3, it should probably link against libutil.so.9 as well. (I am completely new to Haskell/GHC and have no clue what "component" to tag this as. I was looking for a 'distribution' or 'packages' component, but can find none. My apologies in advance for tagging it as 'None') [0]: https://www.haskell.org/ghc/download_ghc_7_10_3.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:43:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:43:41 -0000 Subject: [GHC] #13973: NamedFieldPuns fails for qualified imports if field name is already in scope In-Reply-To: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> References: <044.14fe0677e731332c39b19fae2ee724a6@haskell.org> Message-ID: <059.844b59b5856794f3a391ad54a3f126a2@haskell.org> #13973: NamedFieldPuns fails for qualified imports if field name is already in scope -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13644 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13644 Comment: Closing as a duplicate of #13644. Note that you don't need `NamedFieldPuns` to trigger the panic - this also suffices: {{{#!hs module Test (foo) where import qualified Record as Rec -- The culprit field2 :: () field2 = () foo :: Rec.Record -> Int foo Rec.Record{field2 = field2} = field2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 20:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 20:44:08 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.a380d30da33eace7489cf9b069b8cddb@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13840 => #13840, #13973 Comment: So is #13973. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 22:35:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 22:35:01 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.f2a28d6041a800b5b884e4415615c6a6@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): GHC is behaving according to its manual. See [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:kind this section]. We made a special case for `:kind` some years ago to allow queries like `:kind Map`. The user sensibly wants `Map`'s kind, and we should give it to them. So the TF-saturation requirement is dropped in `:kind`. I support this design choice. On the other hand, it's very suspect in `:kind!`. It's surprising to me, too, that this gives the right result. But, after all, TF evaluation makes fine sense with unsaturated type families -- it's just type inference that gets muddled. So: we could keep the current behavior (which doesn't seem to be hurting anyone), or restrict the behavior of `kind!` to disallow partially applied type families. Maybe an intermediate approach is to keep the current behavior but issue a warning in the event of a partially applied family. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 22:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 22:42:44 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.b6cebfa82d56f5993a5adb1491e16098@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => TypeInType, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 22:47:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 22:47:27 -0000 Subject: [GHC] #13962: GHCi allows unsaturated type family In-Reply-To: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> References: <051.c5d0e1cebec0fdcf8ae288882f64b8ee@haskell.org> Message-ID: <066.1c99afbbb0b9f9373502b4be79354e95@haskell.org> #13962: GHCi allows unsaturated type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I see. I'm a bit embarrassed that I've been doing `:kind Map` all this time and never realized that I was doing something unsavory. I'm curious - how does type inference get muddled exactly? And moreover, is the particular way in which it becomes muddled relevant for `:kind`? If not, then I'd vote to leave things the way they are. Otherwise, we might want to reconsider. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 22:58:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 22:58:07 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.be71d4898aaecabdb9e850ff1a1e265b@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): * comment:2: Sorry, I shouldn't have used this example, since it's not actually tripping up the `ASSERT`. In fact, it does close over the kinds of the type variables, which you can see by looking at the [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584:/compiler/types/TyCoRep.hs#l1897 definition of zipTvSubst]: {{{#!hs zipTvSubst :: [TyVar] -> [Type] -> TCvSubst zipTvSubst tvs tys | debugIsOn , not (all isTyVar tvs) || neLength tvs tys = pprTrace "zipTvSubst" (ppr tvs $$ ppr tys) emptyTCvSubst | otherwise = mkTvSubst (mkInScopeSet (tyCoVarsOfTypes tys)) tenv where tenv = zipTyEnv tvs tys }}} It uses `tyCoVarsOfTypes` to get the tyvars for the in-scope set, so they will include the necessary kind variables. Phew. * comment:3. Aha! What I should have done is split `substTyVar` into a checked version and an unchecked version, and use the unchecked version in `subst_ty` (`subst_ty` is already using `substTyVarBndrUnchecked` [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584:/compiler/types/TyCoRep.hs#l2185 here], so this doesn't make things any less palatable than before). I'll post an update after I've ran `./validate` with this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 23:39:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 23:39:50 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.c524de8e31c9734973823cb6324ea593@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3732 Comment: Happily, it passes `./validate`! I also ran `./validate --slow`, and I couldn't observe any //additional// `ASSERT` failures from this change (there were some `ASSERT` failures related to the substitution invariant before and after this chance, but importantly, the number of them remain unchanged with this patch). Since I'm convinced this will just work, I've submitted Phab:D3732 to Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 13 23:58:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Jul 2017 23:58:43 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.1cf1248592f927b6d8dc45a369457ed6@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3733 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 09:23:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 09:23:04 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.9053f89e656867b955aca7feed03112c@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): I've got a SEGFAULT in a new location which seems related to the same issue: {{{ Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f747043a32f in stg_BLACKHOLE_info () from /nix/store/ka5975xi1b7vcw98a1agqhb0y4gxcwbj- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr_debug- ghc8.2.0.20170704.so [Current thread is 1 (LWP 25315)] warning: File "/nix/store/xfrkm34sk0a13ha9bpki61l2k5g1v8dh- gcc-5.4.0-lib/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto- load". (gdb) bt #0 0x00007f747043a32f in stg_BLACKHOLE_info () from /nix/store/ka5975xi1b7vcw98a1agqhb0y4gxcwbj- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr_debug- ghc8.2.0.20170704.so #1 0x0000000000000000 in ?? () (gdb) info locals No symbol table info available. (gdb) disassemble Dump of assembler code for function stg_BLACKHOLE_info: 0x00007f747043a240 <+0>: mov 0x8(%rbx),%rax 0x00007f747043a244 <+4>: test $0x7,%al 0x00007f747043a246 <+6>: jne 0x7f747043a32c 0x00007f747043a24c <+12>: mov (%rax),%rcx 0x00007f747043a24f <+15>: cmp 0x2d7f2(%rip),%rcx # 0x7f7470467a48 0x00007f747043a256 <+22>: je 0x7f747043a240 0x00007f747043a258 <+24>: cmp 0x2d7e1(%rip),%rcx # 0x7f7470467a40 0x00007f747043a25f <+31>: je 0x7f747043a2a4 0x00007f747043a261 <+33>: cmp 0x2d7b0(%rip),%rcx # 0x7f7470467a18 0x00007f747043a268 <+40>: je 0x7f747043a2a4 0x00007f747043a26a <+42>: cmp 0x2d79f(%rip),%rcx # 0x7f7470467a10 0x00007f747043a271 <+49>: je 0x7f747043a2a4 0x00007f747043a273 <+51>: test $0x7,%al 0x00007f747043a275 <+53>: jne 0x7f747043a345 0x00007f747043a27b <+59>: mov (%rax),%rbx 0x00007f747043a27e <+62>: cmpl $0x1a,-0x8(%rbx) 0x00007f747043a282 <+66>: jb 0x7f747043a34b 0x00007f747043a288 <+72>: cmpl $0x1c,-0x8(%rbx) 0x00007f747043a28c <+76>: jb 0x7f747043a332 0x00007f747043a292 <+82>: cmpl $0x1d,-0x8(%rbx) 0x00007f747043a296 <+86>: jb 0x7f747043a33c 0x00007f747043a29c <+92>: mov %rbx,%rcx 0x00007f747043a29f <+95>: mov %rax,%rbx 0x00007f747043a2a2 <+98>: jmpq *%rcx 0x00007f747043a2a4 <+100>: lea -0xeebb(%rip),%rax # 0x7f747042b3f0 0x00007f747043a2ab <+107>: lea -0x18(%r13),%rcx 0x00007f747043a2af <+111>: mov $0x4,%edx 0x00007f747043a2b4 <+116>: sub $0x8,%rsp 0x00007f747043a2b8 <+120>: mov %rdx,%rsi 0x00007f747043a2bb <+123>: mov %rcx,%rdi 0x00007f747043a2be <+126>: mov %rax,%rcx 0x00007f747043a2c1 <+129>: xor %eax,%eax 0x00007f747043a2c3 <+131>: callq *%rcx 0x00007f747043a2c5 <+133>: add $0x8,%rsp 0x00007f747043a2c9 <+137>: lea 0x6e0(%rip),%rcx # 0x7f747043a9b0 0x00007f747043a2d0 <+144>: mov %rcx,(%rax) 0x00007f747043a2d3 <+147>: mov 0x368(%r13),%rcx 0x00007f747043a2da <+154>: mov %rcx,0x10(%rax) 0x00007f747043a2de <+158>: mov %rbx,0x18(%rax) 0x00007f747043a2e2 <+162>: lea -0x2e299(%rip),%rcx # 0x7f747040c050 0x00007f747043a2e9 <+169>: lea -0x18(%r13),%rdx 0x00007f747043a2ed <+173>: mov %rax,%rsi 0x00007f747043a2f0 <+176>: sub $0x8,%rsp 0x00007f747043a2f4 <+180>: mov %rdx,%rdi 0x00007f747043a2f7 <+183>: mov %rax,%rdx 0x00007f747043a2fa <+186>: xor %eax,%eax 0x00007f747043a2fc <+188>: mov %rdx,%r14 0x00007f747043a2ff <+191>: callq *%rcx 0x00007f747043a301 <+193>: add $0x8,%rsp 0x00007f747043a305 <+197>: test %rax,%rax 0x00007f747043a308 <+200>: je 0x7f747043a240 0x00007f747043a30e <+206>: mov 0x368(%r13),%rax 0x00007f747043a315 <+213>: movw $0x2,0x22(%rax) 0x00007f747043a31b <+219>: mov 0x368(%r13),%rax 0x00007f747043a322 <+226>: mov %r14,0x28(%rax) 0x00007f747043a326 <+230>: jmpq 0x7f7470438d58 0x00007f747043a32b <+235>: nop 0x00007f747043a32c <+236>: mov %rax,%rbx => 0x00007f747043a32f <+239>: jmpq *0x0(%rbp) 0x00007f747043a332 <+242>: cmpl $0x1b,-0x8(%rbx) 0x00007f747043a336 <+246>: jb 0x7f747043a29c 0x00007f747043a33c <+252>: mov 0x8(%rax),%rax 0x00007f747043a340 <+256>: jmpq 0x7f747043a273 0x00007f747043a345 <+261>: mov %rax,%rbx 0x00007f747043a348 <+264>: jmpq *0x0(%rbp) 0x00007f747043a34b <+267>: cmpl $0xf,-0x8(%rbx) 0x00007f747043a34f <+271>: jb 0x7f747043a36d 0x00007f747043a351 <+273>: cmpl $0x19,-0x8(%rbx) 0x00007f747043a355 <+277>: jb 0x7f747043a35d 0x00007f747043a357 <+279>: mov %rax,%rbx 0x00007f747043a35a <+282>: jmpq *0x0(%rbp) 0x00007f747043a35d <+285>: movslq -0x8(%rbx),%rcx 0x00007f747043a361 <+289>: cmp $0x17,%rcx 0x00007f747043a365 <+293>: jne 0x7f747043a29c 0x00007f747043a36b <+299>: jmp 0x7f747043a357 0x00007f747043a36d <+301>: cmpl $0x8,-0x8(%rbx) 0x00007f747043a371 <+305>: jb 0x7f747043a29c 0x00007f747043a377 <+311>: movslq -0x8(%rbx),%rbx 0x00007f747043a37b <+315>: add $0xfffffffffffffff8,%rbx 0x00007f747043a37f <+319>: lea 0x1eca2(%rip),%rcx # 0x7f7470459028 0x00007f747043a386 <+326>: movslq (%rcx,%rbx,8),%rbx 0x00007f747043a38a <+330>: add %rbx,%rcx 0x00007f747043a38d <+333>: jmpq *%rcx End of assembler dump. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 09:29:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 09:29:03 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.c6b0f22e6f9eaf7921d05a74838484f2@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): I've got a hunch that this might be related to the use of a HashMap (from unordered-containers) inside STM transactions. I'm building my program with ordered maps from containers to see if it makes a difference. It'll take a while for the results since Nix has decided that it must rebuild GHC from my local checkout. If this is the case I think I should be able to provide a reproducible case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 10:02:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 10:02:50 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.281c73cd2e5561628e5350ccaa4ee75a@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism 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 Iceland_jack): I guess, since the type synonym returns `r` that its kind should actually be {{{#!hs forall {rep :: RuntimeRep} {rep' :: RuntimeRep}. TYPE rep -> TYPE rep' -> forall (rep'' :: RuntimeRep) -> TYPE rep'' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 10:32:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 10:32:57 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.6f60f10d66ea941f2a697b87499ab2b9@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): My hunch was wrong. Substituting HashMap for Map in the variable stored in a TMVar which threads contend for did not eliminate the segfaults. It made them much more frequent however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 12:20:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 12:20:54 -0000 Subject: [GHC] #13975: GHC can't infer pattern signature, untoucable kinds Message-ID: <051.4cca287a767dfcbce2ba79ffd333d36c@haskell.org> #13975: GHC can't infer pattern signature, untoucable kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeFamilyDependencies, TypeInType, KindSignatures, PolyKinds, PatternSynonyms, GADTs #-} import Data.Kind data T = D | I type SING k = k -> Type type family Sing = (r :: SING k) | r -> k where Sing = ST Sing = SPair data ST :: SING T where SD :: ST D SI :: ST I data SPair :: SING (k, k') where SPair :: Sing a -> Sing b -> SPair '(a, b) pattern DD :: SPair '(D, D) pattern DD = SPair SD SD }}} works.. until we remove the pattern signature for `DD`, then we get {{{ $ ghci-8.0.1 -ignore-dot-ghci /tmp/aur.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/aur.hs, interpreted ) /tmp/aur.hs:21:20: error: • Couldn't match kind ‘k’ with ‘T’ ‘k’ is untouchable inside the constraints: t ~ '(a, b) bound by a pattern with constructor: SPair :: forall k k' (a :: k) (b :: k'). Sing a -> Sing b -> SPair '(a, b), in a pattern synonym declaration at /tmp/aur.hs:21:14-24 ‘k’ is a rigid type variable bound by the inferred type of DD :: SPair t at /tmp/aur.hs:21:9 Possible fix: add a type signature for ‘DD’ When matching the kind of ‘a’ Expected type: Sing a Actual type: ST a • In the pattern: SD In the pattern: SPair SD SD In the declaration for pattern synonym ‘DD’ /tmp/aur.hs:21:23: error: • Couldn't match kind ‘k'’ with ‘T’ ‘k'’ is untouchable inside the constraints: a ~ 'D bound by a pattern with constructor: SD :: ST 'D, in a pattern synonym declaration at /tmp/aur.hs:21:20-21 ‘k'’ is a rigid type variable bound by the inferred type of DD :: SPair t at /tmp/aur.hs:21:9 Possible fix: add a type signature for ‘DD’ When matching the kind of ‘b’ Expected type: Sing b Actual type: ST b • In the pattern: SD In the pattern: SPair SD SD In the declaration for pattern synonym ‘DD’ Failed, modules loaded: none. }}} Restricting the kind of `SPair` to `SPair :: SING (T, T)` gets it to work, can it be made to work bidirectionally? Or can it only work unidirectionally {{{#!hs pattern DD :: () => (a ~ D, b ~ D, res ~ '(a, b)) => SPair res pattern DD <- SPair SD SD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 13:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 13:33:22 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.b2b36e0a177ea89b3498224fcd30fa8f@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Another interesting segfault, again, I believe related to the same root issue: {{{ Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f16a46dc18b in cas (n=, o=596035667054922568, p=0x7f16a46fce88 ) at includes/stg/SMP.h:139 139 includes/stg/SMP.h: No such file or directory. [Current thread is 1 (LWP 3885)] warning: File "/nix/store/xfrkm34sk0a13ha9bpki61l2k5g1v8dh- gcc-5.4.0-lib/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto- load". (gdb) bt #0 0x00007f16a46dc18b in cas (n=, o=596035667054922568, p=0x7f16a46fce88 ) at includes/stg/SMP.h:139 #1 threadPaused (cap=0x1393750, tso=0x421d9dc000) at rts/ThreadPaused.c:326 #2 0x00007f16a46fc275 in stg_returnToSched () from /nix/store/jbrmlni9jhswsdz0rfx5h5qayn8jd96r- ghc-8.2.0.20170704/lib/ghc-8.2.0.20170704/rts/libHSrts_thr_debug- ghc8.2.0.20170704.so #3 0x0000000000000000 in ?? () (gdb) up #1 threadPaused (cap=0x1393750, tso=0x421d9dc000) at rts/ThreadPaused.c:326 326 rts/ThreadPaused.c: No such file or directory. (gdb) x/64a tso->stackobj->sp 0x4217cbee88: 0x7f16a46fc5c8 0x420f67a2d0 0x4217cbee98: 0x7f16aaaaeba8 0x7f16aaaaeb30 0x4217cbeea8: 0xfffffffffffffffe 0x7f16a46fcf80 0x4217cbeeb8: 0x7f16a46fce88 0x420f67a2d0 0x4217cbeec8: 0x7f16aaaaea10 0xfffffffffffffffe 0x4217cbeed8: 0x2 0x7f16aaaaf338 0x4217cbeee8: 0x420c2a39e0 0x420c2a39f8 0x4217cbeef8: 0x4201518f80 0x7f16a46fce88 0x4217cbef08: 0x420c2a3af0 0x7f16aaade098 0x4217cbef18: 0x4220a868aa 0x420c2a3900 0x4217cbef28: 0x4220389af1 0x420bd629e9 0x4217cbef38: 0x420bd626c9 0x420c2a3969 0x4217cbef48: 0x2a3 0xfffffffffffffefa 0x4217cbef58: 0x420c1513f9 0x7f16ab5b47a0 0x4217cbef68: 0x42209c9db9 0x420c151409 0x4217cbef78: 0xffffffffffffff05 0x420bd62460 0x4217cbef88: 0x421d9ac4d9 0x421c790e93 0x4217cbef98: 0x2ab 0x4220389af1 0x4217cbefa8: 0x7f16a46fd2a0 0x7f16a5026cc0 0x4217cbefb8: 0x7f16a46fd800 0xc 0x4217cbefc8: 0x7f16a554d592 0x7f16a5026d80 0x4217cbefd8: 0x421c790eca 0x7f16a46fd800 0x4217cbefe8: 0xc 0x7f16a5582e2a 0x4217cbeff8: 0x7f16a46fc088 0x7f16a9f35a08 0x4217cbf008: 0x4217cbfae1 0x4217cbfaf1 0x4217cbf018: 0x4217f8edea 0x7f16a9f7083b 0x4217cbf028: 0x6465c89002d5d36b 0x40 0x4217cbf038: 0x7f16a9f35a08 0x42198d6069 0x4217cbf048: 0x42198d6079 0x4218bb47d2 0x4217cbf058: 0x7f16a9f7083b 0x6465c89002d5d3ab 0x4217cbf068: 0x8 0x7f16a9f35a08 0x4217cbf078: 0x4217cbfb11 0x4217cbfb21 }}} BTW: By inspecting the stack of using {{{x/64a tso->stackobj->sp}}} I've noticed that the pointer to {{{sigym4zmpropagzmenginezm0zi1zi0zi0zmFERo4wFJ8F465LTBnpBC6B_Sigym4ziPropagziEngine_zdwpolyzugo13_info}}} is always there when it crashes. However, I cannot figure out the teh corresponding haskell function. It seems like it lives in the Sigym4.Propag.Engine but there's no function there named in a similar way to "polyzugo". I believe it could be an inlined/specialized function from another module. Any ideas on how I can I map it back to the haskell world? (I've had no success in figuring it out by reading https://ghc.haskell.org/trac/ghc/wiki/Debugging/CompiledCode) Another interesting thing is that pointers to functions from the 'psqueues' package always seem to be in the stack too when it crashes. Could be a hint on a way to build a small reproducible case. I'll continue investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 14:00:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 14:00:05 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.e65c1306c51843284b9df81d34b49f48@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 hsyl20): GHC uses [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames z-encoding], hence "zd" is "$" and "zu" is "_" . You can remove the `$w` prefix probably introduced by the worker/wrapper transformation, leaving you with `poly_go13` or maybe `poly_go` in the Haskell source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 14:37:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 14:37:36 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.b9a529e107964ac6603d820259e36590@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:13 hsyl20]: > GHC uses [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames z-encoding], hence "zd" is "$" and "zu" is "_" . You can remove the `$w` prefix probably introduced by the worker/wrapper transformation, leaving you with `poly_go13` or maybe `poly_go` in the Haskell source. There's no function by those names in that module, however, I could manage to find "poly_go13" it's header (.hi) file. It's in a binary format which gives me no hints regarding where it might come from. Is there any way to inspect it in a more amicable way? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 15:02:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 15:02:12 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.300c58b32885a5c21641d6ebe654040b@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 mpickering): You can use the `ghc` option `--show-iface` to inspect the `.hi` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 15:19:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 15:19:53 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.4dc8d0da441635cac56029f1cd3e14a1@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): Also, using the gdb command `info line sigym4zmpropagzmenginezm0zi1zi0zi0zmFERo4wFJ8F465LTBnpBC6B_Sigym4ziPropagziEngine_zdwpolyzugo13_info` may also be helpful. I generally compile my programs with `-ddump-simpl -ddump-stg -ddump-opt- cmm -ddump-to-file` when looking at problems so I can refer back to what GHC was working with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 15:52:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 15:52:15 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.d8f0c4d3046a194107555f5cd92ed236@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:14 albertov]: > Replying to [comment:13 hsyl20]: > > GHC uses [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames z-encoding], hence "zd" is "$" and "zu" is "_" . You can remove the `$w` prefix probably introduced by the worker/wrapper transformation, leaving you with `poly_go13` or maybe `poly_go` in the Haskell source. > > There's no function by those names in that module, however, I could manage to find "poly_go13" it's header (.hi) file. It's in a binary format which gives me no hints regarding where it might come from. Is there any way to inspect it in a more amicable way? Thanks! I've found out by compiling with {{{-ddump-simpl}}} that {{{poly_go13}}} seems to be a specialization of {{{Data.Map.lookup}}}: {{{ $wpoly_go13 [InlPrag=[0], Occ=LoopBreaker] :: forall a. Int# -> Int# -> Map BlockIndex a -> Maybe a [GblId, Arity=3, Caf=NoCafRefs, Str=] $wpoly_go13 = \ (@ a) (ww :: Int#) (ww1 :: Int#) (w :: Map BlockIndex a) -> case w of { Bin ipv ipv1 ipv2 ipv3 ipv4 -> case ipv1 of { V2 b1 b2 -> case b1 of { I# y# -> case b2 of { I# y#1 -> case tagToEnum# @ Bool (<# ww y#) of { False -> case tagToEnum# @ Bool (==# ww y#) of { False -> $wpoly_go13 @ a ww ww1 ipv4; True -> case tagToEnum# @ Bool (<# ww1 y#1) of { False -> case tagToEnum# @ Bool (==# ww1 y#1) of { False -> $wpoly_go13 @ a ww ww1 ipv4; True -> Just @ a ipv2 }; True -> $wpoly_go13 @ a ww ww1 ipv3 } }; True -> $wpoly_go13 @ a ww ww1 ipv3 } } } }; Tip -> Nothing @ a } end Rec } }}} where {{{ type BlockIndex = Linear.V2.V2 Int }}} I can relate to the part of my program where this comes from and, interestingly, this was originally a {{{Data.HashMap.Strict.HashMap}}} which I changed to a {{{Data.Map.Strict.Map}}} to see if it made a difference (see comment:10). For some reason, segfaults are much more frequent with the Data.Map (so I've left it like this to help debug). This Map is stored in a TMVar which threads regularly {{{M.lookup blockIx <$> readTMVar}}} neighboring Blocks to send them "work". When the lookup fails they take the lock, create a new Block and a new thread to process it, put the Block back in the Map and put the Map back in the TMVar. So, although the BlockIndex is strict, the value isn't so perhaps this is where shared un-evaluated thunks are created which manifests the bug? (if my intuition about the problem is correct). Anyway, now I have some ideas on how to attempt to reproduce this bug outside of my program, which might be quicker than factoring out the whole engine out of the propietary parts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 15:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 15:59:13 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.65c7ef6611124a23a92c44fd400ddc05@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): > Anyway, now I have some ideas on how to attempt to reproduce this bug outside of my program, which might be quicker than factoring out the whole engine out of the propietary parts. I agree; it would be great if you could extract the essence of the issue into an independent repro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 16:07:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 16:07:03 -0000 Subject: [GHC] #13976: Defined but not used warning on records used by servant-client Message-ID: <050.38911bdbc925afb9255ead9c019cf6c4@haskell.org> #13976: Defined but not used warning on records used by servant-client -------------------------------------+------------------------------------- Reporter: matthewleon | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- When generating an HTTP client through the servant-client lib (https://hackage.haskell.org/package/servant-client), if the various API record accessors go unused elsewhere, -Wunused-top-binds will generate warnings of the style "Defined but not used: `{accessor}`. I believe this is somewhat misleading, as the accessors are indeed "used" in the process of generating the client. Some sample code that will generate a warning for the `release` accessor: {{{ type API = "release" :> Capture "mbid" Mbid :> Get '[JSON] Listing type Mbid = UUID data Listing = Listing { release :: Text } deriving (Show, Generic) instance FromJSON Listing coverArtArchiveAPI :: Proxy API coverArtArchiveAPI = Proxy getListing :: Mbid -> ClientM Listing getListing = client coverArtArchiveAPI }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 16:45:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 16:45:05 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.c8c92eefa7606b2c01c100228418841c@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, this looks plausible. (I think it's the call-stack stuff that makes `bool` inlined less aggressively, but I have not checked.) I think what we want is for the simplifier to do a "cheap and cheerful" bottom-ness analysis on every iteration. See `CoreArity.exprBotStrictness_maybe`. But actually it already very nearly does exactly that. The simplifier already calls `CoreArity.findRhsArity`, which in turn calls `CoreArity.rhsEtaEpandArity`, which calls `arityType` just like `exprBotStrictness_maybe`. So we are already doing all the work (in `arityType`); we just aren't getting the benefit! I have not worked this through, but I think `findRhsArity` could return a boolean flag for "returns bottom" as well as an arity. The the simplifier could use that to set the strictness of the `Id` if it didn't already have (a bottoming) strictness. That way `bool` would get a bottoming strictness and the case expressions would fall way immediately. In a bit more detail perhaps `SimplUtils.tryEtaExpandRhs` could return a new `Id` (with updated arity and perhpas strictness) as well as a new rhs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 16:49:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 16:49:27 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.ce1604b6db1b5a0f486cf15c9ed85b0e@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I have opened a [[https://github.com/haskell/bytestring/pull/132|pull request]] against `bytestring` implementing a more efficient codepath for building string literals. I have confirmed that this new codepath easily fits under the tick limit when compiling the above testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 16:52:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 16:52:10 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.0b72a6569e9105d2cdf491b08029e203@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'll give it a go this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 16:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 16:55:45 -0000 Subject: [GHC] #13976: Defined but not used warning on records used by servant-client In-Reply-To: <050.38911bdbc925afb9255ead9c019cf6c4@haskell.org> References: <050.38911bdbc925afb9255ead9c019cf6c4@haskell.org> Message-ID: <065.c658dbb576286367ea58344096b977ab@haskell.org> #13976: Defined but not used warning on records used by servant-client -------------------------------------+------------------------------------- Reporter: matthewleon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13919 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13919 Comment: This is basically the same issue as #13919, so I'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 17:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 17:07:01 -0000 Subject: [GHC] #13902: Misleading function arity mismatch error with TypeApplications In-Reply-To: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> References: <050.514c9079ae10e5fa5ab2326b10b1fa2b@haskell.org> Message-ID: <065.5c6fe618509e27e3bc3b26ccff7bb421@haskell.org> #13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > {{{#!hs > {-# LANGUAGE TypeApplications #-} > > f :: a -> a > f x = x > > g :: Int > g = f @Int 42 5 > }}} > {{{ > GHCi, version 8.3.20170614: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Main ( Bug.hs, interpreted ) > > Bug.hs:7:5: error: > • Couldn't match expected type ‘Integer -> Int’ > with actual type ‘Int’ > • The function ‘f’ is applied to three arguments, > but its type ‘Int -> Int’ has only one > In the expression: f @Int 42 5 > In an equation for ‘g’: g = f @Int 42 5 > | > 7 | g = f @Int 42 5 > | ^^^^^^^^^^^ > }}} > > That error message is quite confusing to read, since it reports that: > > * `f` is applied to three arguments, which //includes// a visible type > application > * `f` only has one argument, which //excludes// the visible type > application > > We ought to be able to do better. My suggestion would be to report this > instead: > > {{{ > • The function ‘f @Int’ is applied to two arguments, > but its type ‘Int -> Int’ has only one > In the expression: f @Int 42 5 > In an equation for ‘g’: g = f @Int 42 5 > }}} > > Although I'm sure there are other ways the same information could be > conveyed (e.g., `The function ‘f’ is applied to two value arguments`). New description: {{{#!hs {-# LANGUAGE TypeApplications #-} f :: a -> a f x = x g :: Int g = f @Int 42 5 }}} {{{ GHCi, version 8.3.20170614: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:7:5: error: • Couldn't match expected type ‘Integer -> Int’ with actual type ‘Int’ • The function ‘f’ is applied to three arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 | 7 | g = f @Int 42 5 | ^^^^^^^^^^^ }}} That error message is quite confusing to read, since it reports that: * `f` is applied to three arguments, which //includes// a visible type application * `f` only has one argument, which //excludes// the visible type application We ought to be able to do better. My suggestion would be to report this instead: {{{ • The expression ‘f @Int’ is applied to two arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 }}} Although I'm sure there are other ways the same information could be conveyed (e.g., `The function ‘f’ is applied to two value arguments`). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 18:08:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 18:08:56 -0000 Subject: [GHC] #13966: Skip-less stream fusion (was: Missed optimization - loop fusion) In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.7b4f0f2919f26befa9e720d514a559ea@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmspiewak): * priority: low => normal * keywords: => JoinPoints Old description: > I think GHC should be able to optimize func1 into func2, but currently it > doesn't. > > {{{#!hs > data Step s a = Done | Yield s a > > func1 high = loop1 0# 1# where > loop1 acc i = case loop2 i of > Done -> acc > Yield (I# i') (I# x) -> loop1 (acc +# x) i' > > loop2 i = case tagToEnum# (i ># high) :: Bool of > False -> case remInt# i 2# of > 0# -> Yield (I# (i +# 1#)) (I# i) > _ -> loop2 (i +# 1#) > True -> Done > > func2 high = loop1 0# 1# where > loop1 acc i = case tagToEnum# (i ># high) :: Bool of > False -> case remInt# i 2# of > 0# -> loop1 (acc +# i) (i +# 1#) > _ -> loop1 acc (i +# 1#) > True -> acc > }}} > > When using the LLVM backend func2 is almost 4x faster than func1. New description: A simple stream chain {{{#!hs chain :: Int -> Int chain = sum . filter even . enumFromTo 1 }}} doesn't fuse under a Skip-less stream on GHC 8.2-rc3 -O2. Benchmarked against a Skip stream (LLVM backend): {{{ benchmarking Skip-less time 248.9 ms (243.3 ms .. 257.3 ms) 0.998 R² (0.995 R² .. 0.999 R²) mean 250.9 ms (248.1 ms .. 254.7 ms) std dev 5.985 ms (4.831 ms .. 7.311 ms) benchmarking Skip time 61.26 ms (60.39 ms .. 62.44 ms) 0.998 R² (0.997 R² .. 0.999 R²) mean 62.45 ms (61.96 ms .. 62.91 ms) std dev 1.387 ms (1.190 ms .. 1.669 ms) }}} Relevant core (chain1 is Skip-less, chain2 has Skip): {{{ -- RHS size: {terms: 51, types: 27, coercions: 0, joins: 1/2} Main.$wchain1 [InlPrag=NOINLINE] :: Int# -> Int# [GblId, Arity=1, Caf=NoCafRefs, Str=] Main.$wchain1 = \ (ww_s9ep :: Int#) -> letrec { $wloop_s9ea [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Step1 Int Int [LclId, Arity=1, Str=, Unf=OtherCon []] $wloop_s9ea = \ (ww1_s9e8 :: Int#) -> case tagToEnum# @ Bool (># ww1_s9e8 ww_s9ep) of { False -> case remInt# ww1_s9e8 2# of { __DEFAULT -> $wloop_s9ea (+# ww1_s9e8 1#); 0# -> Main.Yield1 @ Int @ Int (GHC.Types.I# (+# ww1_s9e8 1#)) (GHC.Types.I# ww1_s9e8) }; True -> Main.Done1 @ Int @ Int }; } in joinrec { $wloop1_s9el [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wloop1_s9el (ww1_s9ef :: Int#) (ww2_s9ej :: Int#) = case $wloop_s9ea ww2_s9ej of { Done1 -> ww1_s9ef; Yield1 s'_a497 x_a498 -> case x_a498 of { GHC.Types.I# y_a66i -> case s'_a497 of { GHC.Types.I# ww4_X9hA -> jump $wloop1_s9el (+# ww1_s9ef y_a66i) ww4_X9hA } } }; } in jump $wloop1_s9el 0# 1# -- RHS size: {terms: 33, types: 9, coercions: 0, joins: 1/1} Main.$wchain2 [InlPrag=NOINLINE] :: Int# -> Int# [GblId, Arity=1, Caf=NoCafRefs, Str=] Main.$wchain2 = \ (ww_s9dZ :: Int#) -> joinrec { $wloop_s9dV [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wloop_s9dV (ww1_s9dP :: Int#) (ww2_s9dT :: Int#) = case tagToEnum# @ Bool (># ww2_s9dT ww_s9dZ) of { False -> case remInt# ww2_s9dT 2# of { __DEFAULT -> jump $wloop_s9dV ww1_s9dP (+# ww2_s9dT 1#); 0# -> jump $wloop_s9dV (+# ww1_s9dP ww2_s9dT) (+# ww2_s9dT 1#) }; True -> ww1_s9dP }; } in jump $wloop_s9dV 0# 1# }}} The code was adapted from M. Snoyman's blog post "Iterators and Streams in Rust and Haskell". -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 18:10:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 18:10:26 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.d6309a310eb4028afb14df6021e74253@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmspiewak): * Attachment "Main.hs" added. Criterion benchmark -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 18:20:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 18:20:35 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.0f7afb18990af45639e93936d4402a5a@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I now have a [[https://github.com/bgamari/T13916-repro/commit/508c8050f09a6f8a44b0aa526fb06b55a3cfd8d4|simplification]] of the testcase that produces an "MVar object entered!" assertion instead of a segmentation fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 18:55:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 18:55:25 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.e321ed18316110767ed4866df2bca7cc@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So it looks like when we are in `limitMakeEnv.go` we find that `eenvpermission` is the `MVar ()` instead of an `Either (MVar ()) ()`. Consequently when we extract the field while performing the case analysis on it, we extract the `MVar#` instead of an `MVar()` as the code expects. This is how we end up passing a `MVAR_DIRTY` to `readMVar`. It looks like we end up in this situation due to miscompilation. The STG has this in the body of `limitMakeEnv.go`, {{{#!hs sat_s6tv [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Data.Either.Either env_a3xy () #) [LclId] = \r [void_0E] src src src Bracket.$wtakeEnv ww1_s6tk ww2_s6tl ww3_s6tm GHC.Prim.void#; } in ... }}} where, {{{#!hs Bracket.$wtakeEnv [InlPrag=[0]] :: forall env. GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Array# (Control.Concurrent.STM.TMVar.TMVar env) -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, env #) }}} Clearly this is bogus: `$wtakeEnv` returns an `env` whereas `sat_s6tv` is supposed to be returning an `Either`. Presumably stg-lint didn't catch this due to its poor sensitivity to type errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 19:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 19:17:01 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.b0ecfb3db088eba6a519bcccc49c927b@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It turns out the simplified Core output for `s6tv` is even crazier, {{{#!hs let sat_s6tv [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Data.Either.Either env_a3xy () #) [LclId] sat_s6tv = \ (s1_s6tt [Occ=Once, OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> src src src case Bracket.$wtakeEnv @ env_a3xy ww1_s6tk ww2_s6tl ww3_s6tm s1_s6tt of {} } in }}} It seems that somehow the strictness analyser has concluded that `takeEnv` diverges as its strictness signature is, {{{ takeEnv_s5fz :: forall env. Vector (TMVar env) -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, env #) [LclId, Arity=2, Str=b, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 126 0}] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 19:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 19:36:31 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.11fb79e8eebddc6aafbd353ba81de1e8@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a sketch of the structure of `takeEnv` along with strictness signatures, {{{ takeEnv = \ (@ env_a3hT) (x_X3Lx [Dmd=] :: Vector (TMVar env_a3hT)) (eta_B1 [Dmd=] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case x_X3Lx of { Data.Vector.Vector ipv_s4Q7 [Dmd=] ipv_s4Q8 [Dmd=] ipv_s4Q9 [Dmd=] -> joinrec { foldlM_loop_a45q [Occ=LoopBreaker] :: GHC.Types.SPEC -> STM env_a3hT -> Int -> (# GHC.Prim.State# GHC.Prim.RealWorld, env_a3hT #) foldlM_loop_a45q (ds4_a45s [Dmd=] :: GHC.Types.SPEC) (z1_a45t [Dmd=] :: STM env_a3hT) (s1_a45u [Dmd=] :: Int) = ... } in jump foldlM_loop_a45q GHC.Types.SPEC (((src GHC.Prim.retry#) @ env_a3hT) `cast` (Sym (GHC.Conc.Sync.N:STM[0] _R) :: ((GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, env_a3hT #)) :: *) ~R# (STM env_a3hT :: *))) (GHC.Types.I# 0#) } }}} Note how the analyzer somehow concludes hyperstrict demands for all of the binders bound by the case analysis of the `Vector` despite the fact that the whole thing consists of nothing more than a call to `foldlM_loop_a45q` which does not itself diverge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 19:43:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 19:43:27 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.eb1e3e088967a44bd280893c127c3970@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think I see: `foldlM_loop_a45q` places a `C(S)` demand on its second argument and called with this argument being `retry#`. `retry#` has a divergent demand result (namely `Demand.botRes`). This is likely how the analyzer concludes that `takeEnv` will diverge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 19:52:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 19:52:26 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.6c510abc742ebcc94a9cc843b23361e8@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #8091 Comment: It looks like this regressed with the solution to #8091. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 20:07:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 20:07:10 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.9503952dadc3cddd5099a94a3dd86970@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 jmspiewak): A typeclass-based Skip-less stream (also from the blog post) does fuse. {{{#!hs data Step3 s = Done3 | Yield3 s (Item3 s) class Stream3 s where type Item3 s next3 :: s -> Step3 s data EnumFromTo3 a = EnumFromTo3 a a instance (Ord a, Num a) => Stream3 (EnumFromTo3 a) where type Item3 (EnumFromTo3 a) = a next3 (EnumFromTo3 i high) | i > high = Done3 | otherwise = Yield3 (EnumFromTo3 (i + 1) high) i data Filter3 a s = Filter3 (a -> Bool) s instance (Stream3 s, Item3 s ~ a) => Stream3 (Filter3 a s) where type Item3 (Filter3 a s) = a next3 (Filter3 predicate s0) = loop s0 where loop s1 = case next3 s1 of Done3 -> Done3 Yield3 s2 x | predicate x -> Yield3 (Filter3 predicate s2) x | otherwise -> loop s2 sum3 :: (Num (Item3 s), Stream3 s) => s -> Item3 s sum3 = loop 0 where loop total s1 = case next3 s1 of Done3 -> total Yield3 s2 x -> loop (total + x) s2 {-# NOINLINE chain3 #-} chain3 :: Int -> Int chain3 = sum3 . Filter3 even . EnumFromTo3 1 }}} Adding an existential wrapper doesn't break the fusion. {{{#!hs data Stream4 a = forall s. (Stream3 s, Item3 s ~ a) => Stream4 s enumFromTo4 :: (Ord a, Num a) => a -> a -> Stream4 a enumFromTo4 start high = Stream4 (EnumFromTo3 start high) filter4 :: (a -> Bool) -> Stream4 a -> Stream4 a filter4 p (Stream4 s) = Stream4 (Filter3 p s) sum4 :: Num a => Stream4 a -> a sum4 (Stream4 s) = sum3 s {-# NOINLINE chain4 #-} chain4 :: Int -> Int chain4 = sum4 . filter4 even . enumFromTo4 1 }}} {{{ benchmarking typeclass Skip-less time 73.11 ms (72.50 ms .. 73.94 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 69.80 ms (68.86 ms .. 70.72 ms) std dev 2.916 ms (2.483 ms .. 3.577 ms) variance introduced by outliers: 20% (moderately inflated) benchmarking typeclass existential Skip-less time 75.44 ms (74.91 ms .. 76.13 ms) 1.000 R² (0.999 R² .. 1.000 R²) mean 75.44 ms (75.06 ms .. 75.80 ms) std dev 1.118 ms (904.6 μs .. 1.479 ms) }}} Both result in: {{{ Rec { -- RHS size: {terms: 36, types: 11, coercions: 0, joins: 1/1} Main.main_$s$wloop1 [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# [GblId, Arity=3, Caf=NoCafRefs, Str=] Main.main_$s$wloop1 = \ (sc_s9HL :: Int#) (sc1_s9HK :: Int#) (sc2_s9HJ :: Int#) -> joinrec { $wloop2_s9y9 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wloop2_s9y9 (ww_s9y1 :: Int#) (ww1_s9y6 :: Int#) = case tagToEnum# @ Bool (># ww_s9y1 ww1_s9y6) of { False -> case remInt# ww_s9y1 2# of { __DEFAULT -> jump $wloop2_s9y9 (+# ww_s9y1 1#) ww1_s9y6; 0# -> Main.main_$s$wloop1 ww1_s9y6 (+# ww_s9y1 1#) (+# sc2_s9HJ ww_s9y1) }; True -> sc2_s9HJ }; } in jump $wloop2_s9y9 sc1_s9HK sc_s9HL end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 20:08:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 20:08:36 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.530f10b3a8f05a437af7820f2f2d9f3d@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmspiewak): * Attachment "Main.2.hs" added. Added typeclass-based stream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 21:10:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 21:10:23 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.69c0dc971397e1b0e07d66e1ed945f1d@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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 bgamari): #13916 leads me to believe this is strictness signature is too strong. Consider this program, {{{#!hs loop :: [TMVar a] -> STM a -> STM a loop [] m = m loop (x:xs) m = loop xs (m `orElse` takeTMVar x) doIt :: [TMVar Int] -> STM Int doIt xs = atomically $ loop xs retry }}} GHC will currently give `loop` a strictness signature of ``. So this means that if we give `retry#` a divergent result demand GHC incorrectly assume that `loop xs retry` will itself diverge, which is clearly not true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 21:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 21:16:43 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.b46f6321ff5975a4dcb1b104bc9bc02d@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 23:05:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 23:05:46 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.508c69dd855b74a628eb4ab4bac52b4e@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 bgamari): Actually, comment:7 isn't quite right: The fact that `loop` doesn't diverge should be accounted for by the `ExnStr` of the first argument of `orElse`. I would have thought that the `ExnStr` should propagate to the second argument of `loop` during demand analysis but it doesn't. That seems to be the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 23:11:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 23:11:51 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" Message-ID: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | 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 looking into #8091 (see ticket:8091#comment:9) and #13916, I noticed something that I found rather surprising. Consider this program, {{{#!hs hello :: STR Char -> STM Char hello a = a `orElse` pure 'a' }}} Recall that `catchRetry#` (which `orElse` is defined in terms of) has the following demand signature, {{{ }}} Note the `x` here: this means it is `ExnStr`, since it doesn't bottom even if the first argument does (despite the fact that it's strict). So, the question is this: What demand should `hello` place on its first argument? I would have thought that it should be precisely the same as the demand that `catchRetry#` places on **its** first argument. However, the demand analyser seems to conclude this: {{{ }}} Not the lack of an `x`. I believe this may be what causes #13916. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 23:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 23:14:26 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.fe59dd4318f61b4afad82d70b3ad1208@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So after taking a bit a break I came back to this and realized that ticket:8091#comment:7 isn't quite right for the reason articulated in ticket:8091#comment:9. Instead I think the problem is that `ExnStr` demands aren't being pushed outwards when they should be. I've opened #13977 to explore this possibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 14 23:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Jul 2017 23:59:36 -0000 Subject: [GHC] #1399: better support for developing threaded applications in ghci In-Reply-To: <044.6403c653b89ebfd32aad1cfc7b91bd50@haskell.org> References: <044.6403c653b89ebfd32aad1cfc7b91bd50@haskell.org> Message-ID: <059.5d3f8bd861f440b466c65821950dabed@haskell.org> #1399: better support for developing threaded applications in ghci -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: GHCi | Version: 6.6.1 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: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: claus.reinke@… (removed) * cc: claus.reinke@…, Bulat.Ziganshin@…, mentheta (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 00:08:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 00:08:06 -0000 Subject: [GHC] #13978: oddness surrounding aeson 1.0.2.1 on Debian Message-ID: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> #13978: oddness surrounding aeson 1.0.2.1 on Debian -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- per bgamari's request, I am filing this ticket as part of an ongoing plea for help to figure out what is going on. When building aeson 1.0.2.1 on Debian, we get a failure (https://buildd.debian.org/status/fetch.php?pkg=haskell- aeson&arch=amd64&ver=1.0.2.1-2&stamp=1499701762&raw=0) building the testsuite: {{{ [19 of 19] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist- ghc/build/Data/Aeson/TH.p_o ) Preprocessing test suite 'tests' for aeson-1.0.2.1... [ 1 of 13] Compiling Types ( tests/Types.hs, dist- ghc/build/tests/tests-tmp/Types.o ) [ 2 of 13] Compiling Options ( tests/Options.hs, dist- ghc/build/tests/tests-tmp/Options.o ) [ 3 of 13] Compiling Functions ( tests/Functions.hs, dist- ghc/build/tests/tests-tmp/Functions.o ) [ 4 of 13] Compiling Instances ( tests/Instances.hs, dist- ghc/build/tests/tests-tmp/Instances.o ) [ 5 of 13] Compiling Encoders ( tests/Encoders.hs, dist- ghc/build/tests/tests-tmp/Encoders.o ) : can't load .so/.DLL for: /<>/dist- ghc/build/libHSaeson-1.0.2.1-ATVva2eon9U8IQdb5aU6Rk-ghc8.0.2.so (/<>/dist-ghc/build/libHSaeson-1.0.2.1 -ATVva2eon9U8IQdb5aU6Rk-ghc8.0.2.so: undefined symbol: aesonzm1zi0zi2zi1zmATVva2eon9U8IQdb5aU6Rk_DataziAesonziEncodingziInternal_utcTime1_closure) }}} This symbol is *UND* in the .so, but present in Data/Aeson/Encoding/Internal.o and Data/Aeson/Encoding/Internal.dyn_o . Building the testsuite with -O0 causes it to fail with a different symbol. Building aeson with cabal (modulo having to hand-edit tests/Instances.hs to remove the redundant Tagged instance) results in a successful build of the testsuite. However, if I '''cabal configure --enable-tests --enable- library-profiling''' instead of just '''cabal configure --enable-tests''', then the build fails with {{{ [10 of 20] Compiling Data.Aeson.Internal ( Data/Aeson/Internal.hs, dist/build/Data/Aeson/Internal.o ) [11 of 20] Compiling Data.Aeson.Encoding.Builder ( Data/Aeson/Encoding/Builder.hs, dist/build/Data/Aeson/Encoding/Builder.o ) [12 of 20] Compiling Data.Aeson.Encoding.Internal ( Data/Aeson/Encoding/Internal.hs, dist/build/Data/Aeson/Encoding/Internal.o ) [13 of 20] Compiling Data.Aeson.Encoding ( Data/Aeson/Encoding.hs, dist/build/Data/Aeson/Encoding.o ) [14 of 20] Compiling Data.Aeson.Types.ToJSON ( Data/Aeson/Types/ToJSON.hs, dist/build/Data/Aeson/Types/ToJSON.o ) [15 of 20] Compiling Data.Aeson.Types.Class ( Data/Aeson/Types/Class.hs, dist/build/Data/Aeson/Types/Class.o ) [16 of 20] Compiling Data.Aeson.Types ( Data/Aeson/Types.hs, dist/build/Data/Aeson/Types.o ) [17 of 20] Compiling Data.Aeson.Text ( Data/Aeson/Text.hs, dist/build/Data/Aeson/Text.o ) [18 of 20] Compiling Data.Aeson ( Data/Aeson.hs, dist/build/Data/Aeson.o ) [19 of 20] Compiling Data.Aeson.Encode ( Data/Aeson/Encode.hs, dist/build/Data/Aeson/Encode.o ) [20 of 20] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist/build/Data/Aeson/TH.o ) [ 1 of 20] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.p_o ) Data/Aeson/Types/Internal.hs:67:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:76:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0 at unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:77:1: error: Failed to load interface for `Data.Hashable' Perhaps you haven't installed the profiling libraries for package `hashable-1.2.6.1 at hashable-1.2.6.1-BImGDn7vOUG6aLx2AeaDao'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:78:1: error: Failed to load interface for `Data.Scientific' Perhaps you haven't installed the profiling libraries for package `scientific-0.3.5.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:81:1: error: Failed to load interface for `Data.Text' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:85:1: error: Failed to load interface for `Data.Vector' Perhaps you haven't installed the profiling libraries for package `vector-0.12.0.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:87:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0 at unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:88:1: error: Failed to load interface for `Data.Scientific' Perhaps you haven't installed the profiling libraries for package `scientific-0.3.5.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:89:1: error: Failed to load interface for `Data.Vector' Perhaps you haven't installed the profiling libraries for package `vector-0.12.0.1'? Use -v to see a list of the files searched for. [ 2 of 20] Compiling Data.Aeson.Types.Generic ( Data/Aeson/Types/Generic.hs, dist/build/Data/Aeson/Types/Generic.p_o ) Data/Aeson/Types/Generic.hs:40:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. [ 3 of 20] Compiling Data.Aeson.Parser.Unescape ( Data/Aeson/Parser/Unescape.hs, dist/build/Data/Aeson/Parser/Unescape.p_o ) Data/Aeson/Parser/Unescape.hs:13:1: error: Failed to load interface for `Data.Text.Array' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:14:1: error: Failed to load interface for `Data.Text.Encoding.Error' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:15:1: error: Failed to load interface for `Data.Text.Internal' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:16:1: error: Failed to load interface for `Data.Text.Internal.Private' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:17:1: error: Failed to load interface for `Data.Text.Unsafe' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2 at text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. [ 6 of 20] Compiling Data.Aeson.Internal.Time ( Data/Aeson/Internal/Time.hs, dist/build/Data/Aeson/Internal/Time.p_o ) Data/Aeson/Internal/Time.hs:21:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. [ 8 of 20] Compiling Data.Aeson.Internal.Functions ( Data/Aeson/Internal/Functions.hs, dist/build/Data/Aeson/Internal/Functions.p_o ) Data/Aeson/Internal/Functions.hs:18:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. Data/Aeson/Internal/Functions.hs:20:1: error: Failed to load interface for `Data.Hashable' Perhaps you haven't installed the profiling libraries for package `hashable-1.2.6.1 at hashable-1.2.6.1-BImGDn7vOUG6aLx2AeaDao'? Use -v to see a list of the files searched for. Data/Aeson/Internal/Functions.hs:21:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0 at unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. }}} This is interesting because when we build aeson-compat (https://buildd.debian.org/status/package.php?p=haskell-aeson- compat&suite=sid) against the questionable build of aeson, we get {{{ Preprocessing test suite 'aeson-compat-test' for aeson-compat-0.3.6... [1 of 2] Compiling Orphans ( test/Orphans.hs, dist-ghc/build /aeson-compat-test/aeson-compat-test-tmp/Orphans.o ) [2 of 2] Compiling Main ( test/Tests.hs, dist-ghc/build/aeson- compat-test/aeson-compat-test-tmp/Main.o ) /usr/lib/haskell-packages/ghc/lib/x86_64-linux- ghc-8.0.2/aeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU/Data/Aeson/Types/ToJSON.hi Declaration for $fToJSONProxy_$ctoEncoding: Failed to load interface for `Data.Aeson.Encoding.Internal' There are files missing in the `aeson-1.0.2.1' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. Cannot continue after interface file error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 00:18:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 00:18:19 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.cb432f678befeeb130fe8c0e46f22194@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): I think I might see why the demand analyser drops the `x`. Consider `postProcessDmdEnv`, {{{#!hs postProcessDmdEnv :: DmdShell -> DmdEnv -> DmdEnv postProcessDmdEnv ds@(JD { sd = ss, ud = us }) env | Abs <- us = emptyDmdEnv | Str _ _ <- ss , Use One _ <- us = env -- Shell is a no-op | otherwise = mapVarEnv (postProcessDmd ds) env }}} When we get here while demand-analysing the `catchRetry# @Char a` application in `hello` we will have the "shell" equal to `JD {sd = Str ExnStr (), ud = Use One ()}` (as computed as `defer_and_use` by `dmdAnalStar`). The environment we are post-processing is `{aQq->}`. Note that the shell has an `ExnStr` which gets eaten by the `Str _ _ <- ss` case of `postProcessDmdEnv`, meaning we don't transform the environment. I haven't yet done enough reading to know whether this is correct but is seems suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 00:18:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 00:18:27 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.47130247e87116ce7b9d39d988625a89@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > While looking into #8091 (see ticket:8091#comment:9) and #13916, I > noticed something that I found rather surprising. Consider this program, > > {{{#!hs > hello :: STR Char -> STM Char > hello a = a `orElse` pure 'a' > }}} > > Recall that `catchRetry#` (which `orElse` is defined in terms of) has the > following demand signature, > {{{ > > }}} > Note the `x` here: this means it is `ExnStr`, since it doesn't bottom > even if the first argument does (despite the fact that it's strict). > > So, the question is this: What demand should `hello` place on its first > argument? I would have thought that it should be precisely the same as > the demand that `catchRetry#` places on **its** first argument. However, > the demand analyser seems to conclude this: > {{{ > > }}} > > Not the lack of an `x`. I believe this may be what causes #13916. New description: While looking into #8091 (see ticket:8091#comment:9) and #13916, I noticed something that I found rather surprising. Consider this program, {{{#!hs hello :: STR Char -> STM Char hello a = a `orElse` pure 'a' }}} Recall that `catchRetry#` (which `orElse` is defined in terms of) has the following demand signature, {{{ }}} Note the `x` here: this means it is `ExnStr`, since it doesn't bottom even if the first argument does (despite the fact that it's strict). So, the question is this: What demand should `hello` place on its first argument? I would have thought that it should be precisely the same as the demand that `catchRetry#` places on **its** first argument. However, the demand analyser seems to conclude this: {{{ }}} Note the lack of an `x`. I believe this may be what causes #13916. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 00:33:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 00:33:03 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.fe14f34a314c55a9c04b3d7b6653103d@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, as far as short term solutions for 8.2.1 are concerned, there are two possibile workarounds that seem to resolve the issue, * weakening `retry#`'s result demand to `topRes` * weakening `retryCatch#`'s first-argument demand to `lazyApply1Dmd` I suspect that neither of these are the right solution; in the end we should try to fix #13977 (unless, of course, I've horribly misunderstood something). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 01:08:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 01:08:20 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.3505da531f9c8fd115605d4326da7a17@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Is this fixed with 8.2.1-rc3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 04:05:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 04:05:31 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.425da9b9cf611e40fc5de8dea9e443b0@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mqudsi): Either the FreeBSD tarball for 8.2.1-rc3 or FreeBSD's tar is broken because I can't extract the tarball on FreeBSD 10.3 or FreeBSD's 11 on two separate machines on two separate networks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 07:28:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 07:28:33 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.89658459df2717586f6d6782c8b37073@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by mniip): * status: closed => new * resolution: worksforme => Comment: Some of the links do not work. (Not sure if "still" or "again"). {{{ http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/ http://research.microsoft.com/~simonpj/papers/concurrent-haskell.ps.gz http://research.microsoft.com/~simonpj/papers/constraints/index.htm http://research.microsoft.com/~simonpj/papers/ext-f/ }}} It is also worth mentioning that at least the ext-f paper is linked from multiple places in the wiki. Perhaps it'd be a great idea to grep the wiki too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 09:07:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 09:07:33 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.7af427ecceeacc503e7c24d296c6e640@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, this may be due to the fact that we now use `gtar` to produce it. Let will fix this before the final release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 09:09:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 09:09:19 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution Message-ID: <046.b22f0776065bd354178bf07bc0410857@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | 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: #13974 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mentioned in #13974. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 09:09:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 09:09:29 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.6fe506316e1ab267ba9d1a423c1c9b1d@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 09:09:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 09:09:51 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.410a92dd09fb18d198cabd6f812e2946@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Tracking in #13979. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 09:22:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 09:22:39 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.d95a203ba39b0b3110be3b86f79dc27d@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 bgamari): I am rather confused. What concretely is this ticket asking? Are you saying that ghc should reduce the skip+less program to the skip-ful core? Are you proposing stream fusion as an alternative to the foldr/build fusion which currently underlies GHC's list implementation? Something else entirely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 11:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 11:24:04 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.5b4a0e91c5552a3473bcd93389102c84@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Phab:D3738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D3738 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 12:00:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 12:00:36 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.c7afe1fc7e6120adf09c8893c9e8887a@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 jmspiewak): Sorry, after reading the paper on join points I thought GHC would be able to fuse the Skip-less stream. The fact that it does fuse the typeclass version convinced me it's possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 12:20:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 12:20:39 -0000 Subject: [GHC] #13978: oddness surrounding aeson 1.0.2.1 on Debian In-Reply-To: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> References: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> Message-ID: <059.73c00ba6242d2d7b5dc399315fe8f16d@haskell.org> #13978: oddness surrounding aeson 1.0.2.1 on Debian -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 nomeata): Are you sure the `cabal configure --enable-tests --enable-library- profiling` observation is relevant, and not just a sign of a bunch of `libghc-*-prof` packages not being installed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 12:31:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 12:31:23 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.6c525b40f61c8760a3deadd75b51e5ef@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D3740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 12:31:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 12:31:50 -0000 Subject: [GHC] #13940: Reduce duplicate implementations of argument handling on Windows In-Reply-To: <047.8342ee8748562facc1285d21ddca3123@haskell.org> References: <047.8342ee8748562facc1285d21ddca3123@haskell.org> Message-ID: <062.1b84ffb7521e576dde82db9f9c5eea37@haskell.org> #13940: Reduce duplicate implementations of argument handling on Windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Resolution: | Keywords: unicode | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12870 | Differential Rev(s): Phab:D3739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D3739 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 14:06:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 14:06:45 -0000 Subject: [GHC] #13978: oddness surrounding aeson 1.0.2.1 on Debian In-Reply-To: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> References: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> Message-ID: <059.0757b502072f4ee03625557f091952a5@haskell.org> #13978: oddness surrounding aeson 1.0.2.1 on Debian -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 clint): Joachim, I did an '''apt build-dep haskell-aeson''' in that chroot and it installed all the -prof .debs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 18:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 18:10:44 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide Message-ID: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- I'm working on cleaning up the users guide, and I have come across an issue with referencing ghc-flags. Essentially, it has to with flags that take arguments. You can see a couple examples if you go to the flag reference here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html #redirecting-output The top flags all have valid links, but the code to generate them is doing it slightly wrong. Let's consider `-o ⟨filename⟩` for instance. There needs to be a specific reference name for this flag. This name serves a couple purposes. First, it forms the end of the url (i.e. .../separate_compilation.html#ghc-flag--o). Second, the form of cross- references to it (i.e. {{{:ghc-flag:`-o`}}}). There are two options: Option 1 (The current system): We exclude the arguments from the reference name of the flag. So {{{:ghc- flag:`-o`}}} is a valid reference that gets rendered as __-o__. The main issue with this system is loss of information. If someone wanted to include the flags in the link, they would have to do {{{:ghc-flag:`-o ⟨filename⟩ <-o>`}}}, which would render as __-o ⟨filename⟩__ but link to the same place as __-o__. This also leads to possibly different choices for the argument name. In fact, the definition has `⟨file⟩` but the reference table has `⟨filename⟩`. Option 2: We include the arguments in the reference name. So to make the reference, one would have to match the definition exactly: {{{:ghc-flag:`-o ⟨file⟩`}}} which would be rendered as __-o ⟨file⟩__, and {{{:ghc-flag:`-o ⟨filename⟩`}}} would not be a valid reference. This solves the loss of information issue from option 1, but does require the person documenting to check for the exact argument wording. I would argue for the second option as it is more consistent, but either is workable. Also note that the current parser automatically converts < (less than) into ⟨, so dealing with special characters is very easy. And these issues also apply to flags that use '='. I thought it best to ask before I converted everything to one way of dealing with these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 19:06:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 19:06:22 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.6a3f7e59c7cea485e4c465ceaff5c31d@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 mpickering): Here's how I am understanding this post as I have also been thinking about this recently. 1. In the Join Points PLDI paper there is an example in section 5 where join points allows `find` defined in terms of `any` to fuse. The author wants(/expects(?)) this technique to also fuse together normal functional pipelines as well as this simple examples. 2. The introduction of type classes seems irrelevant to the first point. GHC has quite a few optimisations which it uses to eliminate type classes and you can play lots of tricks around this to cause fusion like this to happen. If you look at the code is structured, in `sum` where the specific instance of `next3` is resolved to `Filter3 Int (EnumFromTo Int)` which means that all the consumers nicely line up with each other and hence fuse. The control flow of this program is very different to the first one. 3. A program with a polymorphic return type parametrised by a type class is very similar to a program written in CPS. To see this similarity, when writing a program in CPS in order for execution to continue you must provide a function which says what to do next. When using type classes, you must instead provide the *type* of the result which in then is elaborated to a function or dictionary of functions which explain how to proceed. Thus structuring your program in this way usually allows this kind of fusion to happen. 4. Ah-ha! but purpose of join points is to allow the compiler to optimise code written in direct style as well as code written in continuation passing style so can we do better in this case? The answer to which I don't yet know and I think is an open research problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 21:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 21:28:13 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS Message-ID: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here: {{{ -- F.hs {-# LANGUAGE TypeFamilies #-} module F where type family F a :: * -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A import F type instance F T = Int -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import {-# SOURCE #-} A import F type instance F T = Bool -- A.hs module A where import B import C }}} From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check. But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 23:11:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 23:11:38 -0000 Subject: [GHC] #13982: HEAD GHC+Cabal uses too much memory Message-ID: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> #13982: HEAD GHC+Cabal uses too much memory -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.3 (other) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you install GHC HEAD and bootstrap cabal "2.0.0.0" as submoduled in that, whenever installing any packages cabal will hang for minutes before dependency resolution and will eat about 10 gigabytes of memory. I did a simple profile, {{{ COST CENTRE MODULE SRC %time %alloc packageListFromCache.readPackageDescription Distribution.Client.IndexUtils Distribution/Client/IndexUtils.hs:(714,5)-(722,61) 95.7 99.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 23:38:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 23:38:56 -0000 Subject: [GHC] #13982: HEAD GHC+Cabal uses too much memory In-Reply-To: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> References: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> Message-ID: <059.2b6b8d5a98e049f9c55ed313bf1c700c@haskell.org> #13982: HEAD GHC+Cabal uses too much memory -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.3 (other) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13930 Comment: I believe this is related to #13930. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 15 23:39:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Jul 2017 23:39:12 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.138e52a9c2524b128c5a8c3174e25970@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13982 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13982 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 00:03:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 00:03:31 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.78866972a3fcae5993715d44c2ad3c5a@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3743 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 00:04:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 00:04:29 -0000 Subject: [GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.5fd6949417f66553983c80f17489c157@haskell.org> References: <044.5fd6949417f66553983c80f17489c157@haskell.org> Message-ID: <059.2ccf1b2b9e847f5f0e2f0f731a43d8c4@haskell.org> #13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3742 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3742 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 03:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 03:58:30 -0000 Subject: [GHC] #13982: HEAD GHC+Cabal uses too much memory In-Reply-To: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> References: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> Message-ID: <059.cdfbd583d3f968dcebf9a7c9e358fde9@haskell.org> #13982: HEAD GHC+Cabal uses too much memory -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.3 (other) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): I have a full profiling file but I can't upload it (500 KB). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 05:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 05:01:38 -0000 Subject: [GHC] #13983: Type synonym referred to as datatype in error message Message-ID: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> #13983: Type synonym referred to as datatype in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce the issue, compile this file with GHC 8.0.1, 8.0.2, 8.2.1, or HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import Data.Proxy type Wat = forall (a :: k). Proxy a }}} {{{ GHCi, version 8.3.20170706: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:1: error: • Kind variable ‘k’ is implicitly bound in datatype ‘Wat’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: (k :: *) • In the type declaration for ‘Wat’ | 7 | type Wat = forall (a :: k). Proxy a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The error message mistakenly refers to `Wat` as a datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 09:21:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 09:21:20 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.638a09d2605a9f81b14dc8f5e158a076@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * testcase: debug, T10667 => debug, T10667, simplCore/should_compile/T13658 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 09:35:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 09:35:35 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.82f53c0c6bff164b4271a14c038a25ea@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 jmspiewak): Thank you for your detailed comment. The paper specifically mentions fusing Skip-less filter so indeed I was expecting this example to work. I brought up the typeclass approach because it's very inefficient on 8.0 but on 8.2 it's close to hand written recursion. It seems recursive join points can be used to fuse this stream, but only with the help of some typeclass-specific optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 10:38:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 10:38:34 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.c4feeb48dd3441c6b4fe3f45f73f0ab0@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 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 takenobu): I can fix it. please wait a moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 10:39:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 10:39:45 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern Message-ID: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: panic | Operating System: Unknown/Multiple template-haskell | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this file with HEAD (f656fba19d0cefe05643ddea35d080ea332a6584): {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Panic where import Language.Haskell.TH expr :: IO Exp expr = runQ $ do name <- newName "foo" [| do $(varP name) <- pure (); pure () |] }}} I get this message: {{{ [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170713 for x86_64-unknown-linux): isIrrefutableHsPat: $(varP name) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/hsSyn/HsPat.hs:643:15 in ghc:HsPat Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It compiles normally with GHC 8.2.1-rc2 (20170507). The bug exists in rc3 (20170704). I am unable to perform a more precise bisect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 10:51:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 10:51:22 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.1905cf96bc9c9a9dd793035b64670e83@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Comment (by mbieleck): The bug was probably introduced by 2fcb5c5c3f6c5a5936eeb5dc07b476e5737f12ad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 11:45:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 11:45:51 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.e706c9dc297177ce9f992f38de85cfc1@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 12:09:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 12:09:52 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.21334da5356f6d159259f2e604b148bb@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Changes (by takenobu): * status: new => patch * differential: => Phab:D3745 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 13:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 13:36:16 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.e3e4b745964f802f477a18019f452178@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 supersven): Regarding {{{ -- When the earliest compiler we want to boostrap with is -- GHC 7.2, we can make RealSrcLoc properly abstract }}} Building/Preparation/Tools states: > In general, we support building with the previous 2 major releases, e.g.: > > [...] > > To build 8.0.* you need GHC >= 7.8 [[BR]] > To build 8.2.* you need GHC >= 7.10 So, according to the comment, it should be save to remove the option. I'm now running `validate` to ensure that the option really can be removed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 15:01:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 15:01:04 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.03251d3935d35ff888c6f298006de8a6@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | 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 ezyang): I picked this up again. I looked carefully at where the kind coercion is used. Specifically: * (TyVar case) When matching in `uVar`, it is used to get the two types to the same kind so that `eqType` may succeed. * (TyVar case) In `uUnrefined`, it is used to ensure that the `TvSubst` is well kinded * (CoercionTy case) It is used to extend the `CvSubst` So, although you don't say it explicitly, I think that I will need to pass `kco` around in the TrieMap implementation so that I can implement these methods correctly. One source of awkwardness here is that the TypeMap doesn't currently store `CastTy`, which means any coercions induced by them will be lost to the ether (I think what needs to be done is just to add back a map for CastTy constructor in TypeMap.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 15:32:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 15:32:13 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.a2b5c1118f32b6476e1832568a6955a9@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: AaronFriel (added) Comment: Aaron, as the author of that patch, what are your thoughts? The problem is that `isIrrefutableHsPat` has as an invariant that it should be called //after// the renamer (see [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584:/compiler/hsSyn/HsPat.hs#l639 here]), but your patch calls `isIrrefutableHsPat` directly from the renamer. Do you think it's sensible to have `isIrrefutableHsPat` return `False` for all Template Haskell splices? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 15:36:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 15:36:26 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.e3db65bf563e2ba73564fa7d85c66847@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | 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 ezyang): It also looks like I'm going to have to undo the trieMapView trick, because when unifying I need to distinguish between injective and non- injective parameters, and if it's a pile of nested AppTys that is much more difficult to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 15:59:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 15:59:38 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.542be58d5bb18225c5780d535fb6cce2@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 jmspiewak): I conducted more tests - it's not about the typeclass. Somehow putting the filter predicate in stream state allows fusion to happen. Is it changing the order of inlining? Prevents some other optimization which was clobbering the fusion opportunity? {{{#!hs filter5 :: (a -> Bool) -> Stream1 a -> Stream1 a filter5 predicate (Stream1 s0 next) = Stream1 (Filter3 predicate s0) f where f (Filter3 p s1) = loop s1 where loop s = case next s of Done1 -> Done1 Yield1 s' x | p x -> Yield1 (Filter3 p s') x | otherwise -> loop s' {-# NOINLINE chain5 #-} chain5 :: Int -> Int chain5 = sum1 . filter5 even . enumFromTo1 1 }}} Compiles to: {{{ -- RHS size: {terms: 36, types: 12, coercions: 0, joins: 2/2} Main.$wchain5 [InlPrag=NOINLINE] :: Int# -> Int# [GblId, Arity=1, Caf=NoCafRefs, Str=] Main.$wchain5 = \ (ww_s9EU :: Int#) -> joinrec { $s$wloop_s9QI [Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $s$wloop_s9QI (sc_s9QH :: Int#) (sc1_s9QG :: Int#) = joinrec { $wloop2_s9EA [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] $wloop2_s9EA (ww1_s9Ey :: Int#) = case tagToEnum# @ Bool (># ww1_s9Ey ww_s9EU) of { False -> case remInt# ww1_s9Ey 2# of { __DEFAULT -> jump $wloop2_s9EA (+# ww1_s9Ey 1#); 0# -> jump $s$wloop_s9QI (+# ww1_s9Ey 1#) (+# sc1_s9QG ww1_s9Ey) }; True -> sc1_s9QG }; } in jump $wloop2_s9EA sc_s9QH; } in jump $s$wloop_s9QI 1# 0# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 16:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 16:51:40 -0000 Subject: [GHC] #13983: Type synonym referred to as datatype in error message In-Reply-To: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> References: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> Message-ID: <065.8fe55a6e6b198c7916ac5f67d44039a1@haskell.org> #13983: Type synonym referred to as datatype in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3747 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 17:30:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 17:30:57 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.d9855e1fa525bac48689f6ca21a585da@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Comment (by mbieleck): Replying to [comment:2 RyanGlScott]: > `isIrrefutableHsPat` has as an invariant that it should be called //after// the renamer (see [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584:/compiler/hsSyn/HsPat.hs#l639 here]), but your patch calls `isIrrefutableHsPat` directly from the renamer. I think the comment you mentioned > Both should be gotten rid of by renamer before isIrrefutablePat is called may be wrong. The comment [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584:/compiler/hsSyn/HsExpr.hs#l2088 here] says: > This is the result of splicing a splice. It is produced by the renamer and consumed by the typechecker. It lives only between the two. (this is not directly related to the issue, just stumbled upon this while trying to fix this) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 17:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 17:38:04 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.89c279bdd4227f29630eb840a5b89fb8@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => high Comment: Certainly, I think that comment's claim needs to be removed (or at least tempered), since `isIrrefutableHsPat` is clearly being used in more places than it was originally designed for nowadays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 17:39:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 17:39:39 -0000 Subject: =?utf-8?b?W0dIQ10gIzEzOTg1OiBHSEMgOC4wIHJlZ3Jlc3Npb246IOKAmGs=?= =?utf-8?q?=E2=80=99_is_not_in_scope_during_type_checking=2C_but_?= =?utf-8?q?it_passed_the_renamer?= Message-ID: <050.713def54cc371cef366e72c06648a03c@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13738 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy data family Fam data instance Fam = MkFam (forall (a :: k). Proxy a) }}} On GHC 8.0.1, 8.0.2, 8.2.1, and HEAD, this fails with a GHC internal error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:41: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1vy :-> APromotionErr FamDataConPE] • In the kind ‘k’ In the type ‘(forall (a :: k). Proxy a)’ In the definition of data constructor ‘MkFam’ | 9 | data instance Fam = MkFam (forall (a :: k). Proxy a) | ^ }}} This is a regression, since on GHC 7.10.3, it did not crash: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:21: Data constructor ‘MkFam’ has existential type variables, a context, or a specialised result type MkFam :: forall (k :: BOX). (forall (k :: BOX) (a :: k). Proxy a) -> Fam (Use ExistentialQuantification or GADTs to allow this) In the definition of data constructor ‘MkFam’ In the data instance declaration for ‘Fam’ }}} This smells like #13738, but no `TypeApplications` are involved here, so I decided to open a separate ticket to be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 17:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 17:39:55 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.c67df179583bbe75467dd05171e9995d@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13985 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 18:46:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 18:46:55 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.a225975b4cc2637faee9d9af8b5025c4@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 23:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 23:48:14 -0000 Subject: [GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters Message-ID: <045.43debcfc336746ece79049ad6e0544ea@haskell.org> #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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 function definition works without TypeApplications but fails to parse with the extension enabled: {{{#!hs {-# LANGUAGE TypeApplications #-} module Mininal where foo x₁@True = 10 }}} It also parses correctly with "x" in place of "x₁". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 16 23:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Jul 2017 23:49:19 -0000 Subject: [GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters In-Reply-To: <045.43debcfc336746ece79049ad6e0544ea@haskell.org> References: <045.43debcfc336746ece79049ad6e0544ea@haskell.org> Message-ID: <060.5c62dc97f7d1c0ed896a6f580852408b@haskell.org> #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by Tikhon: Old description: > The following function definition works without TypeApplications but > fails to parse with the extension enabled: > > {{{#!hs > {-# LANGUAGE TypeApplications #-} > module Mininal where > > foo x₁@True = 10 > }}} > > It also parses correctly with "x" in place of "x₁". New description: The following function definition works without TypeApplications but fails to parse with the extension enabled: {{{#!hs {-# LANGUAGE TypeApplications #-} module Mininal where foo x₁@True = 10 }}} It also parses correctly with "x" in place of "x₁". Parse error: {{{ Minimal.hs:5:1-11: error: … Parse error in pattern: foo x₁ @True Compilation failed. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 01:17:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 01:17:52 -0000 Subject: [GHC] #13987: T13701 fails sporadically Message-ID: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> #13987: T13701 fails sporadically -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- T13701 fails sporadically, comments in Phab:D3586 indicate that it happens while the system is under load. I reproduced this issue by duplicating T13701 7 times, making tests T13701[A-H], then running {{{ make test TEST="T13701A T13701B T13701C T13701D T13701E T13701F T13701G T13701H THREADS=8" }}} on my box with 4 cpus. Comparing profiling reports of the test under and not under load, I found the additional allocations to be in SysTools.builderMainLoop.loop. This function busy-waits from when 2 EOFs are received until getProcessExitCode returns a Just. That this is the cause was verified by changing {{{ | otherwise -> loop chan hProcess t p exitcode }}} to {{{ | otherwise -> threadDelay 10000 >> loop chan hProcess t p exitcode }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 01:20:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 01:20:34 -0000 Subject: [GHC] #13987: T13701 fails sporadically In-Reply-To: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> References: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> Message-ID: <058.9f86d31e29c5e267ef1a8c9be55282f8@haskell.org> #13987: T13701 fails sporadically -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * owner: (none) => duog -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 01:21:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 01:21:11 -0000 Subject: [GHC] #13987: T13701 fails sporadically In-Reply-To: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> References: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> Message-ID: <058.91c4cc2bfb7a8df4cb17a48b7f2dba00@haskell.org> #13987: T13701 fails sporadically -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => Phab:D3748 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 01:53:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 01:53:57 -0000 Subject: [GHC] #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters In-Reply-To: <045.43debcfc336746ece79049ad6e0544ea@haskell.org> References: <045.43debcfc336746ece79049ad6e0544ea@haskell.org> Message-ID: <060.46559e728c01df71dc21bed146495e71@haskell.org> #13986: TypeApplications causes parse errors in @-patterns with certain Unicode characters -------------------------------------+------------------------------------- Reporter: Tikhon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 02:02:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 02:02:07 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables Message-ID: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`): {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeInType -XGADTs -fprint-explicit-foralls λ> import Data.Kind λ> data Foo (a :: k) where MkFoo :: (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k1 (a :: k1) k2 (k3 :: k2). k1 ~ * => Foo a }}} Note that `MkFoo` quantifies two extra existential type variables, `k2` and `k3` which are completely unused! Note that this does not occur if the `MkFoo` constructor uses an explicit `forall`: {{{ λ> :set -XScopedTypeVariables λ> data Foo (a :: k) where MkFoo :: forall k (a :: k). (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k (a :: k). k ~ * => Foo a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 06:31:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 06:31:07 -0000 Subject: [GHC] #13989: use templateHaskell type checker panic Message-ID: <048.cc099dafa4315a69c948f9d02bf46b1d@haskell.org> #13989: use templateHaskell type checker panic -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple 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 use acid-state, whci use TemplateHaskell to deriveSafeCopy, the following code will produce a panic {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Service.HAEventBroker where -- this module dispatch HAEvent to remote RDS-Console, -- if failed, persistent to locle storage and deliver later -- Event must keep ordered, aka FIFO -- import Model import Data.Acid import qualified Data.List as DL import Data.SafeCopy import Data.Typeable import Control.Concurrent import Control.Monad data HAEvent = HAEvent Int data EventQueue = EvQ [HAEvent] $(deriveSafeCopy 0 'base ''EventQueue) putEvent :: HAEvent -> Update EventQueue () putEvent e = do EvQ el <- get put $ EvQ (e:el) pollEvent :: Int -> Update EventQueue [HAEvent] pollEvent n = do EvQ el <- get let rl = DL.reverse el let t = DL.take n $ rl let r = DL.reverse $ DL.splitAt (length t) rl put $ EvQ r $(makeAcidic 'EventQueue ['putEvent, 'pollEvent]) publish :: Broker -> HAEvent -> IO () publish broker e = update broker (PutEvent e) consume :: HAEvent -> IO () consume e = return () newtype Broker = Broker { acidState :: AcidState (EventQueue [HAEvent]) } runBroker :: IO Broker runBroker = do broker <- openLocalStateFrom "haBroker/" (EventQueue []) putStrLn "I'm consuming the message queue ..." forkIO $ forever $ doConsume broker return broker where doConsume :: Broker -> IO () doConsume b = do ev <- update (acidState b) (PollEvent n) consume ev }}} stack ghci --ghc-options=-ddump-splices {{{#!hs /Users/LambdaCat/code/haskell/ha- admin/src/Service/HAEventBroker.hs:21:3-37: Splicing declarations deriveSafeCopy 0 'base ''EventQueue ======> instance SafeCopy EventQueue where putCopy (EvQ a1_awJ6) = contain (do { safePut_ListHAEvent_awJ7 <- getSafePut; safePut_ListHAEvent_awJ7 a1_awJ6; return () }) getCopy = contain (cereal-0.5.4.0:Data.Serialize.Get.label "Service.HAEventBroker.EventQueue:" (do { safeGet_ListHAEvent_awJ8 <- getSafeGet; ((return EvQ) <*> safeGet_ListHAEvent_awJ8) })) version = 0 kind = base errorTypeName _ = "Service.HAEventBroker.EventQueue" ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] get_awNI :: t_awNH[tau:1] (CHoleCan: get) [W] put_awOs :: t_awOr[tau:1] (CHoleCan: put) [W] get_awOF :: t_awOE[tau:1] (CHoleCan: get) [W] put_awOK :: t_awOJ[tau:1] (CHoleCan: put)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 08:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 08:12:29 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.77055401231aaca37f17f3dd0f2fb8f2@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 simonpj): > right now, we decide to defer a type family consistency check if the family was recursively defined. I don't like the sound of that. Strange deferring under special circumstances. Can we figure out a more uniform approach? I've lost context here. In your example, modules `B` and `C` seem to have no overlap problem, but `A` does. Can you set out the problem you are trying to solve, ab-initio? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 11:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 11:51:26 -0000 Subject: [GHC] #13989: use templateHaskell type checker panic In-Reply-To: <048.cc099dafa4315a69c948f9d02bf46b1d@haskell.org> References: <048.cc099dafa4315a69c948f9d02bf46b1d@haskell.org> Message-ID: <063.8136808ac5f9949c7616f15a924a6df2@haskell.org> #13989: use templateHaskell type checker panic -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps a dup of #13106. Can you try 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 14:03:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 14:03:47 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.ddc6b2bf8a0e7d6e0fc67ea08a443c7b@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 ezyang): Yeah. The details are in `Note [Don't check hs-boot type family instances too early]`, but reproduced below: * So, the origin of a panic "tcIfaceGlobal (local): not found" is when force the TyThing of a locally defined type prior to having actually typechecked that type. Ordinarily this can't happen (since you can't even get your hands on the TyThing before you've typechecked the type), but when you have an hs-boot file, a placeholder thunk for the TyThing is put into the context, and the onus is on you to avoid forcing this thunk until it is ready. * Type family consistency checking happens prior to any typechecking, and (as first discovered in #11062) it can cause a TyThing of an hs-boot defined type family to be forced too early. Originally, I suggested that we simply do the consistency check after all typechecking was done. But this has its own problem: if we do the consistency check too late, we may end up typechecking Haskell code under inconsistent/overlapping sets of axioms, which could lead to very strange errors. * Thus, we have to defer some of the consistency checks. We first do all of the consistency checks that could not possibly force a TyThing immediately, and then as we finish kind-checking a type family, we then go ahead and do all of the deferred consistency checks involving that family. * What I didn't realize when I originally wrote this patch is that the early forcing isn't limited just to a type family: types which occur in the LHS of overlapping instances (`T` above) also have this problem. So some new solution needs to be found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 15:21:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 15:21:36 -0000 Subject: [GHC] #13989: use templateHaskell type checker panic In-Reply-To: <048.cc099dafa4315a69c948f9d02bf46b1d@haskell.org> References: <048.cc099dafa4315a69c948f9d02bf46b1d@haskell.org> Message-ID: <063.5bb83e4c92e83825f4649a7ecffefc45@haskell.org> #13989: use templateHaskell type checker panic -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Indeed, it's a duplicate of #13106. Moreover, the panic has nothing to do with Template Haskell. Here's the error you get with GHC 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Service.HAEventBroker ( Bug.hs, interpreted ) Bug.hs:25:13: error: Variable not in scope: get :: Update Service.HAEventBroker.EventQueue Service.HAEventBroker.EventQueue | 25 | EvQ el <- get | ^^^ Bug.hs:26:3: error: Variable not in scope: put :: Service.HAEventBroker.EventQueue -> Update Service.HAEventBroker.EventQueue () | 26 | put $ EvQ (e:el) | ^^^ Bug.hs:30:13: error: Variable not in scope: get :: Update Service.HAEventBroker.EventQueue Service.HAEventBroker.EventQueue | 30 | EvQ el <- get | ^^^ Bug.hs:34:3: error: Variable not in scope: put :: Service.HAEventBroker.EventQueue -> Update Service.HAEventBroker.EventQueue [Service.HAEventBroker.HAEvent] | 34 | put $ EvQ r | ^^^ Bug.hs:36:14: error: • Not in scope: data constructor ‘EventQueue’ • In the Template Haskell quotation 'EventQueue | 36 | $(makeAcidic 'EventQueue ['putEvent, 'pollEvent]) | ^^^^^^^^^^^ }}} So the issue is out-of-scope identifiers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 16:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 16:48:57 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.9512de139574b241ac8122145446d0f0@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mbieleck): * cc: mbieleck (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 19:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 19:10:12 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell (was: Kinds should be treated like types in TcSplice) In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.200ff5fd6a3f69eb26a1375aa9fedb07@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: TypeInType 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 RyanGlScott): Actually, there's another way to go about this. Instead of making more things pure, we could make more things monadic. This can be accomplished with the following combinator: {{{#!hs bindCore :: DsM (Core (TH.Q a)) -> (Core a -> DsM (Core (TH.Q b))) -> DsM (Core (TH.Q b)) bindCore dsma f = do { cqa@(MkC qa) <- dsma ; loc <- getSrcSpanDs ; a_name <- newNameAt (mkVarOccFS (fsLit "a")) loc ; let [a_ty] = tcTyConAppArgs (exprType qa) ; let a_id = mkLocalId (localiseName a_name) a_ty ca = MkC (Var a_id) ; MkC qb <- f ca ; let [b_ty] = tcTyConAppArgs (exprType qb) ; repBindQ a_ty b_ty cqa (MkC (Lam a_id qb)) } }}} With `bindCore`, we can retrofit existing uses of `repLKind` with `repLTy`. Here's one example: {{{#!diff diff --git a/compiler/deSugar/DsMeta.hs b/compiler/deSugar/DsMeta.hs index c679981..8acc6eb 100644 --- a/compiler/deSugar/DsMeta.hs +++ b/compiler/deSugar/DsMeta.hs @@ -1043,8 +1044,9 @@ repTy (HsEqTy t1 t2) = do repTapps eq [t1', t2'] repTy (HsKindSig t k) = do t1 <- repLTy t - k1 <- repLKind k - repTSig t1 k1 + bindCore (repLTy k) $ repTSig t1 + -- k1 <- repLKind k + -- repTSig t1 k1 repTy (HsSpliceTy splice _) = repSplice splice repTy (HsExplicitListTy _ _ tys) = do tys1 <- repLTys tys }}} It's somewhat unsavory, but it prevents us from having to change a truckload of combinators in `Language.Haskell.TH.Lib` to take `KindQ` as an argument instead of `Kind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 19:31:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 19:31:59 -0000 Subject: [GHC] #13990: Core Lint error on empty case Message-ID: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: core-lint | Operating System: Unknown/Multiple case | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module: {{{#!hs {-# LANGUAGE EmptyCase #-} module Bug where data Void absurd :: Void -> a absurd v = case v of {} data Foo = Foo !Void absurdFoo :: Foo -> a absurdFoo (Foo x) = absurd x }}} Compiled using `ghc-8.2.0.20170704 -O -dcore-lint Bug.hs` Gives the following error: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** : warning: In a case alternative: (Foo x_ap6 :: Void) No alternatives for a case scrutinee in head-normal form: x_ap6 *** Offending Program *** absurd :: forall a. Void -> a [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] absurd = \ (@ a_apU) (v_ap5 :: Void) -> case v_ap5 of { } absurdFoo :: forall a. Foo -> a [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] absurdFoo = \ (@ a_apY) (ds_dUn :: Foo) -> case ds_dUn of { Foo x_ap6 -> case x_ap6 of { } } -- irrelevant stuff omitted }}} When I manually inline `absurd` or remove the strictness annotation on `Foo`, the error goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 20:15:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 20:15:05 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.40b8b1b7b33e9f9fc80b29d47808d3fc@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mbieleck): Here's another idea, based on comment:15: Replace every coercion resulting from flattening type family applications with `UnivCo`. I think that could fix the problem Simon mentioned, because the resulting `UnivCo` should have the same free variables as the original chain of coercions. But I know approximately nothing about GHC internals, so this may be terribly wrong. I am experimenting with an implementation of this idea. The code is {{{ --- a/compiler/typecheck/TcFlatten.hs +++ b/compiler/typecheck/TcFlatten.hs @@ -1139,16 +1139,18 @@ flatten_fam_app tc tys -- Can be over-saturated -- in which case the remaining arguments should -- be dealt with by AppTys do { let (tys1, tys_rest) = splitAt (tyConArity tc) tys - ; (xi1, co1) <- flatten_exact_fam_app tc tys1 + ; (xi1, _co1) <- flatten_exact_fam_app tc tys1 -- co1 :: xi1 ~ F tys1 -- all Nominal roles b/c the tycon is oversaturated - ; (xis_rest, cos_rest) <- flatten_many (repeat Nominal) tys_rest + ; (xis_rest, _cos_rest) <- flatten_many (repeat Nominal) tys_rest -- cos_res :: xis_rest ~ tys_rest + ; zonkedTy <- liftTcS $ zonkTcType $ mkTyConApp tc tys + ; role <- getRole ; return ( mkAppTys xi1 xis_rest -- NB mkAppTys: rhs_xi might not be a type variable -- cf Trac #5655 - , mkAppCos co1 cos_rest + , mkUnsafeCo role (mkAppTys xi1 xis_rest) zonkedTy -- (rhs_xi :: F xis) ; (F cos :: F xis ~ F tys) ) } }}} Here I'm trying to generate an `UnsafeCo` of the same type as the original. This passes all tests but T13822, which fails with a Core Lint error, and I have no idea why. Can someone help me debug this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 17 23:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Jul 2017 23:03:35 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.dca1c5bff7f3ef4346e92ce5fd3ddc3c@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3751 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3751 Comment: Phab:D3751 addresses the `DsMeta` portion of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 02:02:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 02:02:40 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.8d98ba904135b1dafc19dfaea5ca9741@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | 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 goldfire): There shouldn't be a map for `CastTy` in the trie. See `Note [Non-trivial definitional equality]` in !TyCoRep. Remember that `ty |> co` is equal to `ty` if the kinds are the same. A more interesting scenario: `(t1 |> co1) (t2 |> co2)` is equal to `t1 t2` if the kinds are the same. Note that it might be that neither `co1` nor `co2` is reflexive! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 02:39:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 02:39:17 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.c859b630a08ac07f9eaab3fcbb64e572@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest Comment: Core Lint errors in a release candidate are ''bad''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 02:39:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 02:39:30 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.e94b0b87b5cee963125e9cd161b89a1a@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 02:45:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 02:45:56 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.4f17a75fd26ef5933983e607593b1375@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I do think your proposed solution may fix the problem reported here -- slow compilation -- in my opinion it throws the baby out with the bathwater. Using `mkUnsafeCo` should happen only from `unsafeCoerce#`. There's nothing unsafe going on here, yet the Core code will be littered with what appear to be unsafe coercions. Instead of abusing the current unsafe coercions, the plan above is to introduce a new `OmittedCo` (controlled by `-f` flags) that is quite like `UnsafeCo` (but stores used coercion variables, for instance). Then, when reading the Core, we can tell the difference between the product of `unsafeCoerce#` and something omitted. By the way, I say "may fix" above because this approach might still create the coercion, only to throw it away. If we prevent the creation of the coercion a little earlier, we might have more luck. By the way, I'm sorry to rain on your parade a bit here. I do very much appreciate your just going in to fix this... but I don't think the simple solution here is quite the right approach that will continue to work in the long term. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 02:58:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 02:58:37 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.2fc0d7a1e952db8f12a3b765f7497621@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be fair, this wasn't introduced in GHC 8.2.1. This error also appears in 8.0 as well (but not in 7.10). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 08:14:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 08:14:31 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.590102be22a2d100e7c8fb2ac488828b@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mbieleck): * Attachment "timing.sh" added. Timing script for Types.hs. Requires `fomit-type-family-coercions.patch`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 08:14:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 08:14:54 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.32acfc6c92c11f34c9e81a3b1879815c@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mbieleck): * Attachment "fomit-type-family-coercions.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 08:20:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 08:20:46 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.73343919a1fb9ca973606725a2e8691f@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mbieleck): Thanks for the response. Replying to [comment:36 goldfire]: > Using `mkUnsafeCo` should happen only from `unsafeCoerce#`. There's nothing unsafe going on here, yet the Core code will be littered with what appear to be unsafe coercions. I realize that. I just picked any variant of `UnivCo` to quickly test if this has any chance of working (and actually improving compile times). Of course the right thing to do is to introduce a new `UnivCoProvenance` specifically for this case. > By the way, I say "may fix" above because this approach might still create the coercion, only to throw it away. If we prevent the creation of the coercion a little earlier, we might have more luck. Yes, it might still create the coercion, but at least it will prevent the simplifier from processing it repeatedly later. > I don't think the simple solution here is quite the right approach that will continue to work in the long term. Who said we can't make incremental improvements? If this would be put behind a flag, it should not harm anyone. For the record, here are some timing results (using Types.hs from the ticket): {{{ $ ./timing.sh GHC=inplace/bin/ghc-stage2 N old omit old_tail omit_tail 200 0m0.465s 0m0.404s 0m1.674s 0m0.445s 400 0m0.695s 0m0.504s 0m10.745s 0m0.645s 600 0m1.077s 0m0.614s 0m28.975s 0m0.985s 800 0m1.565s 0m0.755s timeout 0m1.446s 1000 0m2.225s 0m1.075s timeout 0m2.435s 1200 0m3.167s 0m1.426s timeout 0m3.575s 1400 0m4.236s 0m1.705s timeout 0m5.045s 1600 0m5.786s 0m1.654s timeout 0m4.775s 1800 0m5.756s 0m1.955s timeout 0m6.156s 2000 0m7.215s 0m3.106s timeout 0m9.865s }}} `old` is the default behavior, `omit` is my patch. `_tail` variants use the tail recursive type family. The reason I'm so desperate is that it greatly affects my code. I'm using extensible (Vinyl) records computed using some type families. For bigger records, GHC just runs out of memory. This patch helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 08:38:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 08:38:51 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.323971cbe08955417cee5e0d55f63c94@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): @mbieleck Can you please put your patch on phabricator so that we can continue to iterate on it? I am going to try a build now and see how it improves the compile times in my type family heavy code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 09:01:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 09:01:03 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.5a5bbff75c82e5417853ad2c499f3fe6@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mbieleck): * differential: => Phab:D3752 Comment: @mpickering Sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 10:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 10:16:43 -0000 Subject: [GHC] #13982: HEAD GHC+Cabal uses too much memory In-Reply-To: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> References: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> Message-ID: <059.6b6bf99efa87b9c5d6f7b900e6dbe50c@haskell.org> #13982: HEAD GHC+Cabal uses too much memory -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.3 (other) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * Attachment "cabal.prof.part1.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 10:16:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 10:16:52 -0000 Subject: [GHC] #13982: HEAD GHC+Cabal uses too much memory In-Reply-To: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> References: <044.c3b9c5d7c4e9062eebc02e4b69dbd535@haskell.org> Message-ID: <059.a2046bf43124932e6a3252b425e94133@haskell.org> #13982: HEAD GHC+Cabal uses too much memory -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.3 (other) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * Attachment "cabal.prof.part2.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 10:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 10:26:23 -0000 Subject: [GHC] #13978: oddness surrounding aeson 1.0.2.1 on Debian In-Reply-To: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> References: <044.22c4798cda2fcf93d5c59b0fbd204994@haskell.org> Message-ID: <059.656b30c95b3f23f7daa31e68d3b69f1c@haskell.org> #13978: oddness surrounding aeson 1.0.2.1 on Debian -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by LocutusOfBorg): * status: new => closed * resolution: => invalid Comment: This seems to have been fixed by a new patch refresh (some if statement being wrong) Closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:31:22 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.ce8d71f2b4cf4f373403be893d9118bb@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:37 is very convincing, with numbers to back up your claims and your appeal to incremental improvement. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:33:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:33:16 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.722403f531feab3c5639d19d5f041505@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints 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 simonpj): This is a very interesting example, thank you. I note that in HEAD it fuses just fine. I have not yet figured out exactly why, but I want to look at this code, from teh Description: {{{ letrec { $wloop [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Step1 Int Int [LclId, Arity=1, Str=, Unf=OtherCon []] $wloop = \ (ww1_s9e8 :: Int#) -> case tagToEnum# @ Bool (># ww1_s9e8 ww_s9ep) of { False -> case remInt# ww1_s9e8 2# of { __DEFAULT -> $wloop (+# ww1_s9e8 1#); 0# -> Main.Yield1 @ Int @ Int (GHC.Types.I# (+# ww1_s9e8 1#)) (GHC.Types.I# ww1_s9e8) }; True -> Main.Done1 @ Int @ Int }; } in joinrec { $wloop1 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wloop1 (ww1_s9ef :: Int#) (ww2_s9ej :: Int#) = case $wloop ww2_s9ej of { Done1 -> ww1_s9ef; Yield1 s'_a497 x_a498 -> case x_a498 of { GHC.Types.I# y_a66i -> case s'_a497 of { GHC.Types.I# ww4_X9hA -> jump $wloop1 (+# ww1_s9ef y_a66i) ww4_X9hA } } }; } in jump $wloop1 0# 1# }}} Once GHC gets the program into this state, it's not going to be able to optimise it. HEAD somehow avoids this dead end, but I hate things where GHC can get stuck in a dead end. I think this code ''ought'' to optimise just fine. Here's why. Look at thar functionn `$wloop`. It's not a join point becuaes it's not tail-called in the body of the `letrec`. But suppose we transform `$wloop` like this: {{{ let { $wloop [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Step1 Int Int [LclId, Arity=1, Str=, Unf=OtherCon []] $wloop = \x. joinrec $j (ww1_s9e8 :: Int#) = case tagToEnum# @ Bool (># ww1_s9e8 ww_s9ep) of { False -> case remInt# ww1_s9e8 2# of { __DEFAULT -> jump $j (+# ww1_s9e8 1#); 0# -> Main.Yield1 @ Int @ Int (GHC.Types.I# (+# ww1_s9e8 1#)) (GHC.Types.I# ww1_s9e8) }; True -> Main.Done1 @ Int @ Int in jump $j x }}} Now `$wloop` is non-recursive, so we can inline it at its only call site, in `$wloop1`: {{{ joinrec { $wloop1 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wloop1 (ww1_s9ef :: Int#) (ww2_s9ej :: Int#) = case (...the body of $wloop...) of { Done1 -> ww1_s9ef; Yield1 s'_a497 x_a498 -> case x_a498 of { GHC.Types.I# y_a66i -> case s'_a497 of { GHC.Types.I# ww4_X9hA -> jump $wloop1 (+# ww1_s9ef y_a66i) ww4_X9hA } } }; } in jump $wloop1 0# 1# }}} And now the right fusion will happen. The crucial bit was the transformation of `$wloop`: we took a tail- recursive function, introduced a (recursive) join point into it, which made it non-recursive. Even if nothing further happens, the implementation of `$wloop` is a bit more efcient because the tail call is just a branch. But the big thing here is that we can now inline `$wloop` in `$wloop1`. So the idea is this: a transformation to turn a tail-recursive function definition into one that is implemented with a recursive join point. If we had such a transformation, it'd get us out of the dead end. Actually, there's a variant of the Static Argument Transformation ([wiki:StaticArgumentTransformation]) at work here. Consider {{{ f x y = case y of A -> f x y' B -> e2 C -> e3 }}} Here the first argument to `f` is "static"; that is, the same in every call. So we can transform like this {{{ f x y = joinrec $j y = case y of A -> $j y' B -> e2 C -> e3 in $j y }}} Note that `x` isn't passed around in every iteration. There's a GHC module `SAT.hs` which does the static argument transformation, but it is not join-point aware. So we should fix that. One reason we don't currently do SAT all the time is that the results are a bit ambiguous; see Andre Santos's thesis for more, cited on [wiki:StaticArgumentTransformation]. BUT I think that some (maybe most) of the problems with SAT may go away if we restrict SAT to tail-recursive functions that we can turn into `joinrecs`. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:52:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:52:45 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project Message-ID: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- putting-haskell-to-test-0.0.1.0: build (lib + test) Preprocessing library putting-haskell-to-test-0.0.1.0... Preprocessing test suite 'HUnitTest' for putting-haskell-to- test-0.0.1.0... [1 of 1] Compiling Main ( test/HUnitTest/Spec.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/HUnitTest/HUnitTest-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] @?=_a1lM :: t_a1lL[tau:1] (CHoleCan: @?=) [W] testCase_a1m2 :: t_a1m1[tau:1] (CHoleCan: testCase) [W] simpleMathFunction_a1mb :: t_a1ma[tau:1] (CHoleCan: simpleMathFunction) [W] @?=_a1xp :: t_a1xo[tau:1] (CHoleCan: @?=) [W] testCase_a1xB :: t_a1xA[tau:1] (CHoleCan: testCase) [W] simpleMathFunction_a1xK :: t_a1xJ[tau:1] (CHoleCan: simpleMathFunction)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Progress: 1/2 -- While building package putting-haskell-to-test-0.0.1.0 using: /home/local/ANT/chandrak/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:putting-haskell-to-test test:HUnitTest --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:53:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:53:59 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.54c2672187770b652d78e246be355922@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by chandrakoduru): * Attachment "putting-haskell-to-test.zip" added. zipped project directory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:57:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:57:02 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.5722a919dae0cac2695c994df640b970@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 chandrakoduru): Forgot to mention.. I am on Ubuntu 4.4.0-83-generic x86_64 Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial stack --version Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:58:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:58:33 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.972a4a22b0e1e29e7010808f0f5ba7ae@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): As Richard says this is a direction we've been wanting to move for some time. But do read comment:15 above carefully. It's ''crucial'' to keep track of the free coercion variables of a coercion, otherwise GHC may (after discarding coercions) "optimise" a correct program into one that seg- faults. We don't wan that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 12:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 12:59:56 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.7e92da2f42dd8db12ca75028a41b87f9@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by chandrakoduru): * failure: None/Unknown => Compile-time crash or panic * version: 8.0.1 => 8.0.2 * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 13:01:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 13:01:02 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.9456dda12675083abf90243ba5736744@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: Compile-time crash or panic => None/Unknown * version: 8.0.2 => 8.0.1 * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Probably a dup of #13106. (There are many dups of this bug.) Try with a more recent GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 14:24:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 14:24:41 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.5380ed82e90d770090e2985231047c9a@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): After removing many dependencies and some cleanup we've opensourced the engine of the problematic wildfire simulator. Fortunately the bug still manifests itself (which rules out some kind of nasty interaction with the foreign libraries it linked to). To reproduce clone https://github.com/meteogrid/propag , `cabal new-build` it and run the `propag-demo` executable. Using the rc3 pre-release and running with `+RTS -N12` it crashed 100% of the times I've tried (the refactor has increased the change of crash). Sorry for this monster of a reproducible case. It's the best I could do to minimize the amount of third-party dependencies for the time being. I'm planning to remove the dependency on the wildfire-specific stuff which should remove more dependencies (and make it useful as an arbitrary 2D spread automata). I've tried initially to reproduce it starting from scratch but did not succeed so I pulled out all the bigger dependencies (eg: meteogrid/bindings-gdal) which require bindings to c++ libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 14:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 14:32:15 -0000 Subject: [GHC] #8903: Add dead store elimination In-Reply-To: <044.457360c65e33571e0a4f71ea81733822@haskell.org> References: <044.457360c65e33571e0a4f71ea81733822@haskell.org> Message-ID: <059.f3576d938f135195ccf8feb2600141af@haskell.org> #8903: Add dead store elimination -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: CodeGen 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: | -------------------------------------+------------------------------------- Comment (by srb): Im willing to take this on, although I still haven't fully wrapped my head around Hoopl. If it's OK for me to have a go, I would appreciate it if I could have some advice on a few issues: 1) This proposed analysis seems quite similar to what's being done in CmmLive/CmmSink. Would it be a good idea to attempt to incorporate it into those passes? 2) The liveness analysis is also used for inlining assignments which are used once, propagating constants, and pushing down assigments. Is it a good idea to do the same thing with stores? Thanks, Sean -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 14:59:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 14:59:07 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.4292945686f101c23333d31eed64811f@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): Thanks albertov! I'm building your repro as we speak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:09:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:09:27 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.704861aafcc6acfc6e3d74367ec81dd0@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > While looking into #8091 (see ticket:8091#comment:9) and #13916, I > noticed something that I found rather surprising. Consider this program, > > {{{#!hs > hello :: STR Char -> STM Char > hello a = a `orElse` pure 'a' > }}} > > Recall that `catchRetry#` (which `orElse` is defined in terms of) has the > following demand signature, > {{{ > > }}} > Note the `x` here: this means it is `ExnStr`, since it doesn't bottom > even if the first argument does (despite the fact that it's strict). > > So, the question is this: What demand should `hello` place on its first > argument? I would have thought that it should be precisely the same as > the demand that `catchRetry#` places on **its** first argument. However, > the demand analyser seems to conclude this: > {{{ > > }}} > > Note the lack of an `x`. I believe this may be what causes #13916. New description: While looking into #8091 (see ticket:8091#comment:9) and #13916, I noticed something that I found rather surprising. Consider this program, {{{#!hs hello :: STM Char -> STM Char hello a = a `orElse` pure 'a' }}} Recall that `catchRetry#` (which `orElse` is defined in terms of) has the following demand signature, {{{ }}} Note the `x` here: this means it is `ExnStr`, since it doesn't bottom even if the first argument does (despite the fact that it's strict). So, the question is this: What demand should `hello` place on its first argument? I would have thought that it should be precisely the same as the demand that `catchRetry#` places on **its** first argument. However, the demand analyser seems to conclude this: {{{ }}} Note the lack of an `x`. I believe this may be what causes #13916. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:11:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:11:35 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.edaed170dab971ef3493779ac0f553da@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by jmct): * cc: jmct (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:30:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:30:23 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.5c0b78f78679760ed97c0f6c98da9aaf@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: We are going to punt this to 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:30:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:30:46 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.a2e59031f89fcfd4cc78b2edec9a0fb9@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: As this isn't a regression I'm going to bump this off to 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:31:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:31:46 -0000 Subject: [GHC] #13966: Skip-less stream fusion In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.6c6515c67261d4797d1fc8e334fb630a@haskell.org> #13966: Skip-less stream fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering Comment: I can look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:31:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:31:48 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.4aa36f6fb9e916425b4d234c80e63281@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high * milestone: 8.2.2 => 8.4.1 Comment: Actually, perhaps 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 15:43:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 15:43:53 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.43c9194e54a7520c3e7cb0238feeaa43@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): {{{#!patch diff --git a/compiler/basicTypes/Demand.hs b/compiler/basicTypes/Demand.hs index 95c7b79b4f..d777da63f0 100644 --- a/compiler/basicTypes/Demand.hs +++ b/compiler/basicTypes/Demand.hs @@ -1442,7 +1442,8 @@ postProcessDmdResult _ res = res postProcessDmdEnv :: DmdShell -> DmdEnv -> DmdEnv postProcessDmdEnv ds@(JD { sd = ss, ud = us }) env | Abs <- us = emptyDmdEnv - | Str _ _ <- ss + | Str VanStr _ <- ss -- Make sure we don't throw about ExnStrs. + -- See #13977. , Use One _ <- us = env -- Shell is a no-op | otherwise = mapVarEnv (postProcessDmd ds) env -- For the Absent case just discard all usage information }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 16:38:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 16:38:58 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.51faf8874ee6a9cfab0f71ac08766429@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 13722 Related Tickets: | Differential Rev(s): Phab:D3724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3724 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 17:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 17:16:25 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.82f18b09f6981250479ee183ad5bea5d@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mbieleck): Replying to [comment:41 simonpj]: > But do read comment:15 above carefully. It's ''crucial'' to keep track of the free coercion variables of a coercion, otherwise GHC may (after discarding coercions) "optimise" a correct program into one that seg- faults. We don't want that. My hypothesis was is that the coercion returned specifically by `flatten_fam_app` should not have more free variables than the original type (`F arg1 arg2`). I failed to see how example from comment:15 would interact with type families. But I was wrong - `flatten_fam_app` could not only use axioms, but also coercion variables that happen to be in scope. Here's an example that demonstrates bad behavior of `-fomit-type-family- coercions`: {{{#!hs {-# LANGUAGE GADTs, TypeFamilies, UndecidableInstances #-} module Bad where type family Id a data T a where T1 :: Id a ~ Bool => T a f :: T a -> Id a -> Bool f x y = case x of T1 -> not y }}} Core (simplified) without `-fomit-type-family-coercions`: {{{ f = \ (@ a) (x :: T a) (y :: Id a) -> case x of T1 (co :: Id a ~ Bool) -> not (y |> co) }}} Core (simplified) with `-fomit-type-family-coercions`: {{{ f = \ (@ a) (x :: T a) (y :: Id a) -> case x of T1 (co :: Id a ~ Bool) -> not (y |> UnivCo (Id a) Bool) }}} `not (y |> UnivCo (Id a) Bool)` can be floated out, which should not happen. The next obvious thing is to generate the coercion, traverse it to find free variables and discard it, putting free variables in `UnivCo`. I've measured how much just traversing the coercion would impact the performance (using `seqCo`). This results in about 50% slowdown compared to just discarding the coercion (for `timings.sh`). An alternative is to track used coercion variables in `FlattenEnv`, but I don't know how reliable would that be. The in-scope coercion gets pulled in in `lookupFlatCache`, is that right? Are there other places in the flattener which can use coercion variables? I apologise for posting so much comments and code, I want to confirm whether my reasoning is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 17:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 17:18:17 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.6a86f07a458976f7eac92a71ff9c7307@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mbieleck): * Attachment "timing2.txt" added. Impact of forcing the coercion on performance -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 17:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 17:49:19 -0000 Subject: [GHC] #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project In-Reply-To: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> References: <052.6cf2fd659271bc2a5620f47ac9e38e43@haskell.org> Message-ID: <067.c50f8cf560b2c1a720bc48fffe035399@haskell.org> #13991: I was building/testing a haskell project using stack ..suddenly I see the following output. Also attached the project -------------------------------------+------------------------------------- Reporter: chandrakoduru | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Old description: > putting-haskell-to-test-0.0.1.0: build (lib + test) > Preprocessing library putting-haskell-to-test-0.0.1.0... > Preprocessing test suite 'HUnitTest' for putting-haskell-to- > test-0.0.1.0... > [1 of 1] Compiling Main ( test/HUnitTest/Spec.hs, .stack- > work/dist/x86_64-linux/Cabal-1.24.2.0/build/HUnitTest/HUnitTest- > tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = > [W] @?=_a1lM :: t_a1lL[tau:1] (CHoleCan: @?=) > [W] testCase_a1m2 :: t_a1m1[tau:1] (CHoleCan: testCase) > [W] simpleMathFunction_a1mb :: t_a1ma[tau:1] (CHoleCan: > simpleMathFunction) > [W] @?=_a1xp :: t_a1xo[tau:1] (CHoleCan: @?=) > [W] testCase_a1xB :: t_a1xA[tau:1] (CHoleCan: testCase) > [W] simpleMathFunction_a1xK :: t_a1xJ[tau:1] (CHoleCan: > simpleMathFunction)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Progress: 1/2 > -- While building package putting-haskell-to-test-0.0.1.0 using: > /home/local/ANT/chandrak/.stack/setup-exe-cache/x86_64-linux/Cabal- > simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- > work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:putting-haskell-to-test > test:HUnitTest --ghc-options " -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure 1 New description: {{{ putting-haskell-to-test-0.0.1.0: build (lib + test) Preprocessing library putting-haskell-to-test-0.0.1.0... Preprocessing test suite 'HUnitTest' for putting-haskell-to- test-0.0.1.0... [1 of 1] Compiling Main ( test/HUnitTest/Spec.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/HUnitTest/HUnitTest-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] @?=_a1lM :: t_a1lL[tau:1] (CHoleCan: @?=) [W] testCase_a1m2 :: t_a1m1[tau:1] (CHoleCan: testCase) [W] simpleMathFunction_a1mb :: t_a1ma[tau:1] (CHoleCan: simpleMathFunction) [W] @?=_a1xp :: t_a1xo[tau:1] (CHoleCan: @?=) [W] testCase_a1xB :: t_a1xA[tau:1] (CHoleCan: testCase) [W] simpleMathFunction_a1xK :: t_a1xJ[tau:1] (CHoleCan: simpleMathFunction)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Progress: 1/2 -- While building package putting-haskell-to-test-0.0.1.0 using: /home/local/ANT/chandrak/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:putting-haskell-to-test test:HUnitTest --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 18:45:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 18:45:56 -0000 Subject: [GHC] #13957: Allow deriving multiparameter type classes with representationally equal arguments In-Reply-To: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> References: <051.ca574959cfdab34f025a33626b0b8745@haskell.org> Message-ID: <066.6a1644841235e78214ac1422823620d9@haskell.org> #13957: Allow deriving multiparameter type classes with representationally equal arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): We cannot both have `SIEVE I (->)` and `SIEVE Identity (->)` if we assume a functional dependency, similar to #13404 where an analogous example would compile {{{#!hs class SIEVE p where type SIEVE_ty p :: Type -> Type sIEVE :: p a b -> (a -> SIEVE_ty p b) instance SIEVE (->) where type SIEVE_ty (->) = Identity sIEVE :: (a -> b) -> (a -> Identity b) sIEVE f = f >>> Identity newtype ARR a b = ARR (a -> b) deriving newtype SIEVE }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 19:52:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 19:52:30 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.c9737a7c46bfe567936e81a0e214865c@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3756 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 19:52:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 19:52:59 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.868561ec4d524de35cc7475d5ee9be9f@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3756 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 20:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 20:10:45 -0000 Subject: [GHC] #13992: Error message, room for improvement (polykinds) Message-ID: <051.6f945668be54c814cbc564ab110fec2b@haskell.org> #13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constraint the kind of `a :: Type`, it would be nice if GHC could reference kind variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 20:11:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 20:11:28 -0000 Subject: [GHC] #13992: Error message, room for improvement (polykinds) In-Reply-To: <051.6f945668be54c814cbc564ab110fec2b@haskell.org> References: <051.6f945668be54c814cbc564ab110fec2b@haskell.org> Message-ID: <066.90f8750233b3e0f1d6c5733167776ad6@haskell.org> #13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Something like > > {{{#!hs > -- • No instance for (Show (Compose Proxy Proxy a)) > -- arising from the 'deriving' clause of a data type declaration > -- Possible fix: > -- use a standalone 'deriving instance' declaration, > -- so you can specify the instance context yourself > -- • When deriving the instance for (Show (FlipProxy a)) > > {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, > KindSignatures #-} > > import Data.Functor.Compose > import Data.Proxy > import Data.Kind > > newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) > deriving newtype > Show > }}} > > where the solution is to constraint the kind of `a :: Type`, it would be > nice if GHC could reference kind variables. New description: Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constrain the kind of `a` to `Type`, it would be nice if GHC could reference kind variables. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 20:28:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 20:28:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.bda57f407edd19c623609ea780022883@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13780 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I was just about to do this. But then I had second thoughts. Right now, we take it as a general rule that the following two declarations are the same: {{{#!hs data G1 a where MkG1 :: G1 Bool data G2 a = (a ~ Bool) => MkG2 }}} and indeed this is true today. But if we throw out `~` in kinds, as proposed here, then only `'MkG1` would be usable in a type. `'MkG2` would be an error, violating our general rule. About Givens: GADT pattern-matching in terms must be very fancy, because the GADT pattern-match relates a runtime thing to a compile-time thing. Figuring out how to do this time travel required several PhDs to be earned. On the other hand, GADT pattern-matching in types need not be nearly so advanced, because everything is compile-time. Indeed, GHC's current implementation of type-level GADT pattern-matching is somewhat simplistic, not using Givens at all. (More below, as I'm sure you'll be curious.) So, even though a `~` in a kind never gives rise to a Given, they are still useful and can be matched against in a type family. How type-level GADT pattern matching works: Let's look at an example. {{{#!hs type family F1 (a :: G k) :: k where F1 MkG1 = True }}} This would seem to require fancy GADT pattern matching. After all, we declare that the return kind be `k` for some unknown `k`, and yet we return `True :: Bool`. However, this really works by doing ''kind- matching''. That is, the definition is elaborated to make its kind variables explicit: {{{#!hs type family F1 (k :: Type) (a :: G k) :: k where F1 Bool MkG1 = True }}} Because type families can pattern-match on kinds, this is hunky dory. The ''caller'' is responsible for showing that `k` is really `Bool`. This sounds terrible, though: what has happened to the expressiveness of GADTs? Nothing bad. Of course the caller can figure out what `k` should be, because it has the same information this function does. (This is very different in terms, where a GADT parameter is learned by a ''runtime'' pattern match. No phase distinction in type families!) This trick has its limits, of course: you can't usefully use a constraint of the form `F a ~ G a` in a kind. I do want to fix that some day. But not today. And, in the meantime, it's unclear if I should fix this ticket and violate the general rule at the top of this comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 20:31:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 20:31:15 -0000 Subject: [GHC] #12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds) In-Reply-To: <051.e4e7a903cc2028990cc937a0b2bfe043@haskell.org> References: <051.e4e7a903cc2028990cc937a0b2bfe043@haskell.org> Message-ID: <066.e2b5c1cb9e7fdd4287f3d97f2704cf07@haskell.org> #12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11480 #12025 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: UndecidableSuperClasses, TypeInType => UndecidableSuperClasses Comment: Upon review, I don't think this is all that related to `TypeInType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 20:57:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 20:57:03 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.12a6ed8acad2ac22295d885681be31e6@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13982 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): My apologies, Simon: I believe I was mistaken when I said this required profiling to reproduce. This can be reproduced with current GHC `master` with, {{{ $ git clone git://github.com/haskell/cabal $ cd cabal $ ghc-pkg unregister Cabal $ cabal install Cabal/ --allow-newer $ cabal install cabal-install/ --allow-newer --only-dependencies $ cd cabal-install $ cabal build }}} The `unregister Cabal` bit is necessary for some GHC versions due to Cabal bug [[https://github.com/haskell/cabal/issues/4509|#4509]]. For the record, a quick profile reveals that most of the allocations seem to be coming from `Distribution.ParseUtils` and `Distribution.Compat.ReadP` (both in `Cabal`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:11:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:11:48 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity (was: Skip-less stream fusion) In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.74c4ec0b1a4510d59070e64449a86efe@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: JoinPoints => JoinPoints, StaticArgumentTransformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:18:21 -0000 Subject: [GHC] #13310: Cut a new array release In-Reply-To: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> References: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> Message-ID: <061.5674262a09b8a68b724a2d816123ddac@haskell.org> #13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is 0.5.2.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:18:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:18:53 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.f41da18dc70f0fc40234e8543c0bd5ab@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping to 8.4 since this is non-essential for release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:35:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:35:26 -0000 Subject: [GHC] #13993: Certain inter-module specializations run out of simplifier ticks Message-ID: <045.c6bc8515dbb94daa199675ba8f625d65@haskell.org> #13993: Certain inter-module specializations run out of simplifier ticks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #9630 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A modification of ezyang's test case in #9630 yields the below. Triggering specialization in a separate module can run the simplifier out of ticks. Notably, moving the definition of `T` into `GenSpec` resolves the problem. Unlike #9630 proper, this seems to cause trouble going back as far as GHC 7.4. {{{#!hs module GenSpec where import Gen import GHC.Generics -- Trigger specialization tput :: T -> Put tput = gput . from }}} {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fno-warn-missing-methods #-} module Gen where import GHC.Generics import Control.Monad import Control.Applicative import Data.Monoid data PairS a = PairS a !(() -> ()) newtype PutM a = Put { unPut :: PairS a } -- Use of this writer monad seems to be important; IO speeds it up type Put = PutM () --type Put = IO () -- binary has INLINE pragmas on most of the instances but you can still -- trigger bad behavior without them. instance Functor PutM where fmap f m = Put $ let PairS a w = unPut m in PairS (f a) w -- Just to appease AMP instance Applicative PutM where pure = return (<*>) = ap instance Monad PutM where return a = Put $ PairS a id m >>= k = Put $ let PairS a w = unPut m PairS b w' = unPut (k a) in PairS b (w . w') class GBinary f where gput :: f t -> Put -- Forcing the dictionary to have two elements hurts -- the optimizer a lot. not_used :: f t instance GBinary a => GBinary (M1 i c a) where gput = gput . unM1 instance Binary a => GBinary (K1 i a) where gput = put . unK1 instance (GBinary a, GBinary b) => GBinary (a :*: b) where gput (x :*: y) = gput x >> gput y class Binary t where put :: t -> Put instance Binary () where put () = return () data T = T () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () deriving Generic }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:36:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:36:38 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.79fb2291cc3eab098b9418e25e761317@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): Phab:D3656 #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: As the regression ''seems'' to be fixed, I've opened #13993 to address the longer-standing issue and am closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:39:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:39:58 -0000 Subject: [GHC] #13994: STG lint failure on master Message-ID: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- As of 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98 building with this `build.mk` results in an STG lint failure, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} The failures occurs while building `libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o` and are of the form, {{{ *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [in body of lambda with binders m0_scBi :: State# s_a2Ej -> State# s_a2Ej, s1_scBj :: State# s_a2Ej] s'_scBk is out of scope : warning: [RHS of $j1_sdij :: (# BigNat, GmpLimb# #)] Let(rec) binder ‘$j1_sdij’ has unlifted type ‘(# BigNat, GmpLimb# #)’ RHS: (elided for brevity) : warning: [RHS of $j4_sdQ1 :: (# BigNat, BigNat #)] Let(rec) binder ‘$j4_sdQ1’ has unlifted type ‘(# BigNat, BigNat #)’ RHS: (elided) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:50:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:50:37 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.96cb2cdd7322f5a91da371512fb85205@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be very reluctant to have a complicated solution that was hard to be sure was correct here. (e.g. tracking covasrs in `FlattenEnv`.) I'm surprised that finding the free variables of a coercion is so expensive. Zonking traerses coercions anyway. Suppose the result of zonking a coercion was always `UnivCo t1 t2 free-vars`. Then to zonk `Trans c1 c2` you can zonk `c1` and `c2`, and unition their free vars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 21:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 21:52:17 -0000 Subject: [GHC] #8903: Add dead store elimination In-Reply-To: <044.457360c65e33571e0a4f71ea81733822@haskell.org> References: <044.457360c65e33571e0a4f71ea81733822@haskell.org> Message-ID: <059.1747442087ba08e6bbbf6b2c1417f8f5@haskell.org> #8903: Add dead store elimination -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: CodeGen 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: email@…, michal.terepeta@…, kavon@… (added) Comment: cc'ing folk interested in Hoopl, who may be able to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 18 23:44:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Jul 2017 23:44:59 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.7bfc0180714b7090b061d43311dacdbc@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: => Phab:D3753 Comment: I've made the changes Simon suggested to Phab:D3753. Unfortunately, the redundant cases still aren't removed until the simplification pass after float out, by which point we've already wasted a bunch of time. Consider {{{#!hs module Serialize where data Result a = Success a | Error String instance Functor Result where {-# INLINE fmap #-} fmap | bool = f | bool = f where bool = undefined f = undefined }}} We get {{{#!hs ==================== Simplifier ==================== 2017-07-18 23:33:20.811559426 UTC Max iterations = 4 SimplMode {Phase = InitialPhase [Gentle], inline, rules, eta-expand, no case-of-case} ... bool_s2b7 :: forall a. a [LclId, Str=x, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=NEVER}] bool_s2b7 = \ (@ a_a1Xw) -> undefined @ 'GHC.Types.LiftedRep @ a_a1Xw ($dIP_s2b6 `cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N _N) :: (GHC.Stack.Types.CallStack :: *) ~R# (?callStack::GHC.Stack.Types.CallStack :: Constraint))) }}} which looks great (there's an `x`!), but we still have {{{#!hs $cfmap_aU6 [InlPrag=INLINE (sat-args=0)] :: forall a b. (a -> b) -> Result a -> Result b [LclId, Str=x, -- Yay for the x, of course Unf=...] $cfmap_aU6 = \ (@ a_aUa) (@ b_aUb) -> case bool_s2b7 @ Bool of { False -> case bool_s2b7 @ Bool of { False -> Control.Exception.Base.patError @ 'GHC.Types.LiftedRep @ ((a_aUa -> b_aUb) -> Result a_aUa -> Result b_aUb) "Serialize.hs:(7,5)-(21,21)|function fmap"#; True -> undefined @ 'GHC.Types.LiftedRep @ ((a_aUa -> b_aUb) -> Result a_aUa -> Result b_aUb) ($dIP_s2aW `cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N _N) :: (GHC.Stack.Types.CallStack :: *) ~R# (?callStack::GHC.Stack.Types.CallStack :: Constraint))) }; True -> undefined @ 'GHC.Types.LiftedRep @ ((a_aUa -> b_aUb) -> Result a_aUa -> Result b_aUb) ($dIP_s2aW `cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N _N) :: (GHC.Stack.Types.CallStack :: *) ~R# (?callStack::GHC.Stack.Types.CallStack :: Constraint))) } }}} For some reason, we're not eliminating the two `case`s on `bool_s2b7 @ Bool`. I'm not sure where to look next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 00:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 00:26:54 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 In-Reply-To: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> References: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> Message-ID: <058.f2c5d4c196ae7f44bb5f08673c6ff393@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): {{{ $ cabal unpack lame==0.1.1 $ cd lame-0.1.1 $ cabal install --only-dependencies --enable-library-profilng $ ghc Codec/Audio/LAME -prof -fprof-auto-exported }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 05:15:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 05:15:44 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.d2e27af318015f529cb0765b6ee92b63@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): I have did some benchmarks[https://github.com/winterland1989/stdio/tree/newFD/bench/diskIO here], my conclusion is that under concurent disk I/O situations, safe FFI can cause a slow down up to 50%. The problem is if the disk is slow enough, or the file is not in page cache, then safe FFI may be a good choice. OTOH, if a blocking read doesn't take too much time, we'd better simply issue an unsafe read. I can't answer all the questions you're asking now though, i'm thinking for disk I/O a small thread pool maybe a better answer, since the I/O throughput will not increase or even downgrade when conncurrent number exceed a certain value. (for example, libuv do this). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 05:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 05:26:12 -0000 Subject: [GHC] #13995: provide hook for 'setNumCapabilities' Message-ID: <045.a7b67335ebe430d03da335824a08db15@haskell.org> #13995: provide hook for 'setNumCapabilities' -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- This request if straight forward: i want to run some code when user call `setNumCapabilities`. I'm making a [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs stripped timing wheel implementation], and the problem is obvious: we keep an array of timer managers just like I/O managers, but we have to ask user to call something like `lowResTimerManagerCapabilitiesChanged` so that we can re-allocate new array, which is unreasonable. The same problem exists in some stripped resource pool implementation, so i proposed {{{ -- this is not exported capabilityChangedHook :: IORef (IO ()) capabilityChangedHook = unsafePerformIO $ newIORef (return ()) -- this is exported to user addCapabilityChangedHook :: IO () -> IO () addCapabilityChangedHook f = do atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) setNumCapabilities :: ... setNumCapabilities = ... ... -- somewhere inside setNumCapabilities hook <- readIORef capabilityChangedHook hook ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 05:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 05:29:14 -0000 Subject: [GHC] #13995: provide hook for 'setNumCapabilities' In-Reply-To: <045.a7b67335ebe430d03da335824a08db15@haskell.org> References: <045.a7b67335ebe430d03da335824a08db15@haskell.org> Message-ID: <060.50a032f1315c722c5c41e50a3759434f@haskell.org> #13995: provide hook for 'setNumCapabilities' -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by winter: Old description: > This request if straight forward: i want to run some code when user call > `setNumCapabilities`. > > I'm making a > [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs > stripped timing wheel implementation], and the problem is obvious: we > keep an array of timer managers just like I/O managers, but we have to > ask user to call something like `lowResTimerManagerCapabilitiesChanged` > so that we can re-allocate new array, which is unreasonable. > > The same problem exists in some stripped resource pool implementation, so > i proposed > > {{{ > -- this is not exported > capabilityChangedHook :: IORef (IO ()) > capabilityChangedHook = unsafePerformIO $ newIORef (return ()) > > -- this is exported to user > addCapabilityChangedHook :: IO () -> IO () > addCapabilityChangedHook f = do > atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) > > setNumCapabilities :: ... > setNumCapabilities = ... > ... > -- somewhere inside setNumCapabilities > hook <- readIORef capabilityChangedHook > hook > ... > }}} New description: This request is straight forward: i want to run some code when user call `setNumCapabilities`. I'm making a [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs stripped timing wheel implementation], and the problem is obvious: we keep an array of timer managers just like I/O managers, but we have to ask user to call something like `lowResTimerManagerCapabilitiesChanged` so that we can re-allocate new array, which is unreasonable. The same problem exists in some stripped resource pool implementation, so i propose {{{ -- this is not exported capabilityChangedHook :: IORef (IO ()) capabilityChangedHook = unsafePerformIO $ newIORef (return ()) -- this is exported to user addCapabilityChangedHook :: IO () -> IO () addCapabilityChangedHook f = do atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) setNumCapabilities :: ... setNumCapabilities = ... ... -- somewhere inside setNumCapabilities hook <- readIORef capabilityChangedHook hook ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 05:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 05:40:26 -0000 Subject: [GHC] #13995: provide hook for 'setNumCapabilities' In-Reply-To: <045.a7b67335ebe430d03da335824a08db15@haskell.org> References: <045.a7b67335ebe430d03da335824a08db15@haskell.org> Message-ID: <060.8322f563d7f37cccff072c980595f16a@haskell.org> #13995: provide hook for 'setNumCapabilities' -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by winter: Old description: > This request is straight forward: i want to run some code when user call > `setNumCapabilities`. > > I'm making a > [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs > stripped timing wheel implementation], and the problem is obvious: we > keep an array of timer managers just like I/O managers, but we have to > ask user to call something like `lowResTimerManagerCapabilitiesChanged` > so that we can re-allocate new array, which is unreasonable. > > The same problem exists in some stripped resource pool implementation, so > i propose > > {{{ > -- this is not exported > capabilityChangedHook :: IORef (IO ()) > capabilityChangedHook = unsafePerformIO $ newIORef (return ()) > > -- this is exported to user > addCapabilityChangedHook :: IO () -> IO () > addCapabilityChangedHook f = do > atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) > > setNumCapabilities :: ... > setNumCapabilities = ... > ... > -- somewhere inside setNumCapabilities > hook <- readIORef capabilityChangedHook > hook > ... > }}} New description: This request is straight forward: i want to run some code when user call `setNumCapabilities`. I'm making a [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs stripped timing wheel implementation], and the problem is obvious: we keep an array of timer managers just like I/O managers, but we have to ask user to call something like `lowResTimerManagerCapabilitiesChanged` so that we can re-allocate new array, which is unreasonable. The same problem exists in some stripped resource pool implementation, so i propose {{{ -- this is not exported capabilityChangedHook :: IORef (IO ()) capabilityChangedHook = unsafePerformIO $ newIORef (return ()) -- this is exported to user, and can be called within unsafePerformIO addCapabilityChangedHook :: IO () -> IO () addCapabilityChangedHook f = do atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) setNumCapabilities :: ... setNumCapabilities = ... ... -- somewhere inside setNumCapabilities hook <- readIORef capabilityChangedHook hook ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 07:45:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 07:45:20 -0000 Subject: [GHC] #13996: Non-cheap primop is duplicated Message-ID: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> #13996: Non-cheap primop is duplicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Conal Elliot [https://mail.haskell.org/pipermail/ghc- devs/2017-July/014407.html writes]: I have {{{ exampleC :: Double -> Double -> Double exampleC = \ t -> let s = sin t in \ x -> x + s }}} But the `sin` ends up being pushed inside the lambda by the optimiser, like so: {{{ exampleC = \ t x -> x + sin t }}} So if I do `map (exampleC v) xs` I end up computing `sin v` once for each element of `xs` rather than once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 07:49:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 07:49:57 -0000 Subject: [GHC] #13996: Non-cheap primop is duplicated In-Reply-To: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> References: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> Message-ID: <061.9fd8885a79c8f58313282e3dbc71cbf8@haskell.org> #13996: Non-cheap primop is duplicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): It’s a cost-model thing. GHC finds that the call to `sin` amounts to a single call to the primop `sinDouble#`. Is that cheap? If so, better to push it inside the inner lambda, so the two lambdas come together (generally a big win). E.g. if it was a single ‘add’ instruction, definitely better to push it inside. Look at `PrimOp.primOpIsCheap`; you’ll see that “cheapness” is approximated by * no side effects * cant fail * is a single instruction (i.e not a call to an out-of-line run-time system procedure) These three properties are set in `prelude/primops.txt.pp` Alas, `sinDouble#` satisfies all three things so it’s regarded as cheap. As Joachim says this may just be the wrong cost model for you. What to do? * Mitigate: `-fno-lambda-eta-expansion` * Hack to make `sin` look expensive: in `primops.txt.pp` set `can_fail` to true. This isn't true, but it's always safe. It'll have other minor effects on optimising `sin` but I doubt it'll matter. * The Right Thing: add a `is_expensive` property for each primop and set it in `primops.txt.pp`. That's a bit more work, but it lets us say what we want. I don't feel strongly about which path to take. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 09:24:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 09:24:17 -0000 Subject: [GHC] #13996: Non-cheap primop is duplicated In-Reply-To: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> References: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> Message-ID: <061.57abf342adac2f73e5bc58a88abf1bcd@haskell.org> #13996: Non-cheap primop is duplicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 mboes): > better to push it inside the inner lambda, so the two lambdas come together (generally a big win). Note in particular that `-fno-lambda-eta-expansion` can be a huge pessimization in the following way. Consider this program: {{{#!hs module Main where f :: Double -> Double -> Double f t = let s = sin t in \x -> x + s main = do print $ sum [ f t x | t <- [1..10000], x <- [1..10000]] }}} `ghc --make -O2` yields a program that runs in constant space. Whereas adding `-fno-do-lambda-eta-expansion` to the command-line yields a program that segfaults, because its memory consumption blew up and it ultimately ran out of space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 09:58:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 09:58:04 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.5702b9d89b3ef562714222460234138c@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:20 bgamari]: > Thanks albertov! I'm building your repro as we speak. Thanks! Did you manage to reproduce the segfault? By the way, I forgot to warn you that this creates a temporary work directory using `System.IO.Temp.withSystemTempDirectory` named `propag-work-XXXX`. It is mean to be cleared after running but if it crashes it wont be so make sure you clean them as they can add up to a lot of space after many experiments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:22:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:22:40 -0000 Subject: [GHC] #13997: GHCi panic: "Loading temp shared object failed" when adding a new module Message-ID: <047.e53ac4ac38bae04bc44bd8eea090ad18@haskell.org> #13997: GHCi panic: "Loading temp shared object failed" when adding a new module -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: panic GHCi | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Files: {{{#!hs -- Bug.hs module Bug where import Bug2 bug = bug2 -- Bug2.hs module Bug2 where bug2 = () }}} Steps to reproduce: 1. Create the files as above 2. Start GHCi: {{{ $ ghc-8.2.0.20170704 --interactive -fobject-code λ> :load Bug Ok, 2 modules loaded. }}} 3. Without exiting GHCi, add a new file: {{{#!hs -- NewModule.hs module NewModule where newFn = () }}} and change `Bug2.hs` to: {{{#!hs module Bug2 where import NewModule bug2 = newFn }}} to introduce a transitive dependency `Bug -> Bug2 -> NewModule`. 4. In GHCi {{{ λ> :reload [2 of 3] Compiling Bug2 ( Bug2.hs, Bug2.o ) Ok, 3 modules loaded. λ> bug ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc22212_0/libghc_4.so: undefined symbol: NewModule_newFn_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem also exists without `-fobject-code`. The error message is different: {{{ λ> bug ghc: ^^ Could not load 'NewModule_newFn_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: NewModule_newFn_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} Also affects GHC 8.0.2 and 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:41:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:41:40 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.b0818ff299244710c9e8073b8d7f7418@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): I have managed to reproduce it a few times although it does seem to take a while. Moreover, it (perhaps not surprisingly) is quite dependent upon paralellism. I was unable to reproduce it in a reasonable amount of time on my dual-core, four-thread laptop. However, on my 4-core, eight-thread server I was able to reproduce it within ten minutes or so. How many cores does your test environment have? Also, for the sake of My first step is to test whether the fix to #13615 is to blame; the problem indeed appears to be a race condition and instrumenting the code can easily hide the problem. For instance, I was unable to reproduce the issue even once while running the program under `rr` overnight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:56:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:56:43 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.e79c4b0c48e978ffd12157e3d61a2456@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Replying to [comment:22 bgamari]: > I have managed to reproduce it a few times although it does seem to take a while. Moreover, it (perhaps not surprisingly) is quite dependent upon paralellism. I was unable to reproduce it in a reasonable amount of time on my dual-core, four-thread laptop. However, on my 4-core, eight-thread server I was able to reproduce it within ten minutes or so. How many cores does your test environment have? I'm testing on a 6-core, 12-thread machine. It is indeed hard to reproduce although it is no much more frequent. I've noticed that giving a large `-N` value to the RTS increases the odds. I'm testing with `-N30`. Have you tried increasing this value way over your number of cores? Another interesting thing is that without this [https://github.com/meteogrid/propag/blob/master/app/Main.hs#L69 pause] I was unable to reproduce the crash and noticed that a breakpoint I had set at `suspendComputation` was never being hit. Adding this pause causes `suspendComputation` to be called multiple times and eventually manifests the problem (when running outside gdb). Maybe playing with that pause helps increasing the odds in your environment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:56:59 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.8d2568616354637f3e71b167be51c7ca@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): mqudsi, how are you seeing the extraction fail? When I attempt to extract the tarball I see, {{{ $ tar -xf ghc-8.2.0.20170704-x86_64-portbld-freebsd.tar.xz.1 ghc-8.2.0.20170704/utils/hp2ps/dist/build/tmp/hp2ps: Can't create 'ghc-8.2.0.20170704/utils/hp2ps/dist/build/tmp/hp2ps' ghc-8.2.0.20170704/utils/haddock/dist/build/tmp/haddock: Can't create 'ghc-8.2.0.20170704/utils/haddock/dist/build/tmp/haddock' ghc-8.2.0.20170704/utils/hsc2hs/dist-install/build/tmp/hsc2hs: Can't create 'ghc-8.2.0.20170704/utils/hsc2hs/dist-install/build/tmp/hsc2hs' ghc-8.2.0.20170704/utils/ghc-pkg/dist-install/build/tmp/ghc-pkg: Can't create 'ghc-8.2.0.20170704/utils/ghc-pkg/dist-install/build/tmp/ghc-pkg' ghc-8.2.0.20170704/utils/hpc/dist-install/build/tmp/hpc: Can't create 'ghc-8.2.0.20170704/utils/hpc/dist-install/build/tmp/hpc' ghc-8.2.0.20170704/utils/runghc/dist-install/build/tmp/runghc: Can't create 'ghc-8.2.0.20170704/utils/runghc/dist-install/build/tmp/runghc' ghc-8.2.0.20170704/ghc/stage2/build/tmp/ghc-stage2: Can't create 'ghc-8.2.0.20170704/ghc/stage2/build/tmp/ghc-stage2' tar: Error exit delayed from previous errors. }}} but otherwise the extraction appears to have been successful. Is this what you see as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:58:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:58:46 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.4222cac0838ce86ea98820e5d919e761@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Any update on this, goldfire? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 12:58:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 12:58:53 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.c2a63c3588b461b82bd8fe1818cdae14@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 13:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 13:06:27 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.4d05791bbd94dca67be579b6ae398e88@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 albertov): Reducing the block size [https://github.com/meteogrid/propag/blob/master/app/Main.hs#L33 here] (to an even number) should also help increasing the odds of a crash since the program will create more (non-OS) threads -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 14:08:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 14:08:45 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.d73c0f2521fb67d61e5e37a7e64d8d1a@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > This is a follow up ticket for #13803, since I wanted to fix the > immediate bug in #13803 without having to deal with the more complicated > case here: > > {{{ > -- F.hs > {-# LANGUAGE TypeFamilies #-} > module F where > type family F a :: * > > -- A.hs-boot > module A where > data T > > -- B.hs > {-# LANGUAGE TypeFamilies #-} > module B where > import {-# SOURCE #-} A > import F > type instance F T = Int > > -- C.hs > {-# LANGUAGE TypeFamilies #-} > module C where > import {-# SOURCE #-} A > import F > type instance F T = Bool > > -- A.hs > module A where > import B > import C > }}} > > From what I wrote: right now, we decide to defer a type family > consistency check if the family was recursively defined. If the RHS > refers to a recursively defined type, there's no problem: we don't need > to look at it for consistency checking. But if the LHS is recursively > defined, as is in this example, we DO need to defer the check. > > But it's a bit irritating to figure out whether or not there's actually a > reference to a recursively defined type in the LHS, since this involves > traversing the LHS types, and if we're not careful we'll end up pulling > in the TyThing anyway. There are two other possibilities: (1) always > defer checking instances which are defined inside the recursive look (by > looking at the Name of the axiom), or (2) annotating IfaceAxiom with the > set of boot types its LHS refers to, for easy checking. Not entirely sure > what the best action is. New description: This is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here: {{{ -- F.hs {-# LANGUAGE TypeFamilies #-} module F where type family F a :: * -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A import F type instance F T = Int -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import {-# SOURCE #-} A import F type instance F T = Bool -- A.hs module A where import B import C data T = T }}} From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check. But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 14:25:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 14:25:20 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor Message-ID: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- I have a situation that's shown up in my `quantification` library that I believe is an issue with GHC's typeclass method defaulting mechanism. Here is a self-contained example: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE GADTs #-} import Data.Type.Equality class EqForall f where eqForall :: f a -> f a -> Bool class EqForall f => EqForallPoly f where eqForallPoly :: f a -> f b -> Bool default eqForallPoly :: TestEquality f => f a -> f b -> Bool eqForallPoly = defaultEqForallPoly defaultEqForallPoly :: (TestEquality f, EqForall f) => f a -> f b -> Bool defaultEqForallPoly x y = case testEquality x y of Nothing -> False Just Refl -> eqForall x y data Atom = AtomInt | AtomString | AtomBool data Value (a :: Atom) where ValueInt :: Int -> Value 'AtomInt ValueString :: String -> Value 'AtomString ValueBool :: Bool -> Value 'AtomBool instance TestEquality Value where testEquality (ValueInt _) (ValueInt _) = Just Refl testEquality (ValueString _) (ValueString _) = Just Refl testEquality (ValueBool _) (ValueBool _) = Just Refl testEquality _ _ = Nothing instance EqForall Value where eqForall (ValueInt a) (ValueInt b) = a == b eqForall (ValueString a) (ValueString b) = a == b eqForall (ValueBool a) (ValueBool b) = a == b instance EqForallPoly Value main :: IO () main = putStrLn "done" }}} This fails to compile both with GHC 8.0 and with GHC 8.2rc3. The error reads: {{{ default_sig_limitation.hs:40:10: error: • Expecting one more argument to ‘Value’ Expected a type, but ‘Value’ has kind ‘Atom -> *’ • In the type ‘Value’ In the expression: Main.$dmeqForallPoly @Value In an equation for ‘eqForallPoly’: eqForallPoly = Main.$dmeqForallPoly @Value }}} If I replace `EqForallPoly` instance with something more explicit, it will compile just fine: {{{ instance EqForallPoly Value where eqForallPoly = defaultEqForallPoly }}} Fortunately, this workaround isn't bad at all. I don't really mind it, but I thought I'd bring it up here in case it bites someone else in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 14:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 14:34:47 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.3a864197adbcfd20b16ca1d14f94fa21@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): Hm, seems to work for 7.8.4/8.0.1 on my end -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 14:41:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 14:41:22 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.d46dd028c289213baed2e30fc36f17e2@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3001 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Thank you for fixing this! Without this we were looking at `15%` compile time regression between `-g` and no `-g`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:05:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:05:53 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.829298807102091819c78db2845ce185@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mqudsi): Yes, I see the same. The build subsequently fails on `hp2ps` as well; so I presume something went wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:17:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:17:55 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.0b932e1fcda20144c24a8a0e87660574@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: It works on GHC 8.0.1 and earlier, but not on 8.0.2 or later. This can be explained by the fact that the way GHC typechecks default implementations received a drastic overhaul in 8.0.2. Unfortunately, that's been the root of many bugs... That being said, I have a hunch what is going on here. From inspecting the `-ddump-tc-trace` output, one can observe that GHC gives the following type signature for `$dmeqForallPoly`: {{{ tcInferId Main.$dmeqForallPoly :: forall k (f :: k -> *). EqForallPoly f => forall (a :: k) (b :: k). TestEquality f => f a -> f b -> Bool }}} Notice that the `k` comes //before// `f`. However, in the generated `EqForallPoly Value` instance (which can be seen with `-ddump-deriv`): {{{ Main.EqForallPoly [Main.Atom, Main.Value] Main.eqForallPoly = Main.$dmeqForallPoly @(Main.Value) }}} It's using `TypeApplications` to instantiate `k` to `Value`. This is wrong, however, since we really want to be instantiating //`f`// to `Value`. That is, we'd rather generate this code: {{{ instance EqForallPoly Value where eqForallPoly = $dmeqForallPoly @Atom @Value }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:19:14 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.8dfd109a2c28d238b52b2fbaea1abf01@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 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 bgamari): I have confirmed that c1c0985416a6f9766c03d361449f556905bf8e1d really is the first bad commit. I also noticed that it is possible to reproduce the crash using `forkIO` instead of `forkOS`, which makes it a bit easier to debug. Presumably this is safe since there are no native dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:22:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:22:55 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.8d1a39180ae56f5ebddaa3f4e0777f6b@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): Just as well, perhaps the `k` in `$dmeqForallPoly` shouldn't be available for visible type application in the first place. Indeed, the code which generates `Main.$dmeqForallPoly @(Main.Value)` already [http://git.haskell.org/ghc.git/blob/d7b17517e26007f537feab490509c0e13e0e239a:/compiler/typecheck/TcInstDcls.hs#l1569 filters out] invisible type arguments, but it seems that the `k` in `$dmeqForallPoly` isn't properly marked as invisible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:42:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:42:35 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.638743063f51b884ab4a78671f6b68ae@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | TypeFamilies, Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3759 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 15:57:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 15:57:52 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.bc5fbf563bead480ddefb9b09a6b045d@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): I'm 99% sure the culprit is [http://git.haskell.org/ghc.git/blob/d7b17517e26007f537feab490509c0e13e0e239a:/compiler/typecheck/TcTyDecls.hs#l771 here]: {{{#!hs mkDefaultMethodType :: Class -> Id -> DefMethSpec Type -> Type -- Returns the top-level type of the default method mkDefaultMethodType _ sel_id VanillaDM = idType sel_id mkDefaultMethodType cls _ (GenericDM dm_ty) = mkSpecSigmaTy cls_tvs [pred] dm_ty where cls_tvs = classTyVars cls pred = mkClassPred cls (mkTyVarTys cls_tvs) }}} The second case (`GenericDM`) is what constructs the type of `$dmeqForallPoly`. Notice that it's using `mkSpecSigmaTy` to prepend the `forall k (f :: k -> *). EqForallPoly f => ...` bit to the rest of the type. However, because it's using `mkSpecSigmaTy`, every class tyvar binder has a visibility of `Specified`, meaning they'll all be available for visible type application, which isn't what we want. However, I'm not sure how to inform GHC that `k` should be invisible, but `f` should be visible, in this code. The problem is that the `Class` data type [http://git.haskell.org/ghc.git/blob/d7b17517e26007f537feab490509c0e13e0e239a:/compiler/types/Class.hs#l52 doesn't store any visibility information for its type variables]... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:01:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:01:09 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.15bf9cdb052094df50114f24968e86a2@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Yes: the visiblity of the `k` type parameter for `$dmeqForAllPoly` is somehow inconsistent with that of the class. See `Note [TyBinders and ArgFlags]` in `TyCoRep`. I have a fix in progress. As usual you have nailed the right place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:05:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:05:44 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.82681e85cfad874615cc108da625ced0@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): Woo, Simon to the rescue! Out of curiosity, are you trying to fix this by changing the visibility of `k`, or changing the codegen to spit out `$dmeqForallPoly @Atom @Value` instead? The former fix sounds more principled, but I think harder, since it seems that GHC doesn't track visibility for class tyvars like I would have imagined: {{{ λ> :type +v eqForallPoly eqForallPoly :: forall k (f :: k -> *). EqForallPoly f => forall (a :: k) (b :: k). f a -> f b -> Bool }}} I would have expected instead: {{{ λ> :type +v eqForallPoly eqForallPoly :: forall {k} (f :: k -> *). EqForallPoly f => forall (a :: k) (b :: k). f a -> f b -> Bool }}} But this should probably go in a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:25:18 -0000 Subject: [GHC] #13996: Non-cheap primop is duplicated In-Reply-To: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> References: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> Message-ID: <061.f29efe4a007aef3dad454603e09f4027@haskell.org> #13996: Non-cheap primop is duplicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 conal): Thanks for the explanation, Simon. The eta-expansion policy sounds very sensible to me, and now I understand that more expensive computations will not get pushed under lambdas. If GHC's cost model turns out not to fit my use, I can add some simple post-GHC transformations on the representation I use for generating GPU code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:33:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:33:28 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.b4cc54f55e999fc74ef87cf13729a794@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > For some reason, we're not eliminating the ... I assume this is just in the ''first'' simplifier run, when `case-of-case` is off? In the second simplifier run, the `case` gets eliminated, correct? I know why this is. In `Simplify` we have: {{{ simplExprF1 env (Case scrut bndr _ alts) cont | sm_case_case (getMode env) = simplExprF env scrut (Select { sc_dup = NoDup, sc_bndr = bndr , sc_alts = alts , sc_env = env, sc_cont = cont }) | otherwise = do { (env', scrut') <- simplExprF (zapFloats env) scrut $ mkBoringStop (substTy env (idType bndr)) ; let scrut'' = wrapJoinFloats (seJoinFloats env') scrut' env'' = env `addLetFloats` env' ; rebuildCase env'' scrut'' bndr alts cont } }}} That is, if `case-of-case` is off, we simplify the scrutinee in a trivial continuation, and then wrap the alternatives around it. So disabling case-of-case has also disabled case-of-bottom. I did this fairly recently, which accounts for the change. Let me think about a better way. Meanwhile you are working on that `botSig` stuff, making it work with functions too, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:36:41 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.f2e3a5c7722c507b69a82e380af357de@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:19 simonpj]: > Meanwhile you are working on that `botSig` stuff, making it work with functions too, right? Already done. It could probably use a bit of cleanup/optimization, but I was waiting with that to see if I can get to the payoff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:37:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:37:23 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.04526325839cd5f8ba34d75d313e5378@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): > The problem is that the Class data type.... But the `classTyCon` has everything. The `classTyVars` are redundant, just there for convenience. I'm fixing it by using the visiblity of the class (tycon) parameters and using that consistently. `mkSpecSigmaTy` is deeply suspect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 16:57:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 16:57:05 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.76178bee7a8c330e64d2da4a4fadbece@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): >I have did some benchmarks​ here, my conclusion is that under concurent disk I/O situations, safe FFI can cause a slow down up to 50%. I can't reproduce this result. I've checked out your benchmark and see the following, == unsafe == {{{ [1250 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m0.657s user 0m0.000s sys 0m1.035s [1251 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m1.766s user 0m0.000s sys 0m1.912s [1251 ben at ben-laptop diskIO(master)] $ time bin/unsafe-ffi 10m real 0m1.460s user 0m0.008s sys 0m1.570s }}} == safe == {{{ [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m real 0m0.867s user 0m0.000s sys 0m0.966s [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m ^[[A real 0m0.473s user 0m0.001s sys 0m0.636s [1252 ben at ben-laptop diskIO(master)] $ time bin/safe-ffi 10m real 0m0.794s user 0m0.009s sys 0m0.864s }}} If anything, it seems that `safe` FFI is dramatically **faster** than `unsafe`. Admittedly this is rather surprising, but I wouldn't expect a factor of two slower for this particular test. In the `safe` case `perf` confirmed that less than 3% of runtime was spent in `suspendThread` and `resumeThread` combined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 17:10:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 17:10:32 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.ea288d4458ee4981d242fdea62b8baf3@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): Replying to [comment:7 simonpj]: > But the `classTyCon` has everything. The `classTyVars` are redundant, just there for convenience. Oops, I overlooked that. Also, please ignore the noise in the latter part of comment:6 - the type signature wasn't pretty-printing the way I expected because I neglected to enable `-fprint-explicit-foralls`. If you do, you'll get: {{{ λ> :set -fprint-explicit-foralls λ> :type +v eqForallPoly eqForallPoly :: forall {k} (f :: k -> *). EqForallPoly f => forall (a :: k) (b :: k). f a -> f b -> Bool }}} as expected. So that is working as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 18:16:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 18:16:42 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.21ad2c9433559c3d5dff23eeb68abd19@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Phab:D3754 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D3754 Comment: As it turns out, yes! All fixed on my end. Right now, I have a raft of bugfixes that just need to get validated and such. This is one of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 18:56:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 18:56:06 -0000 Subject: [GHC] #13996: Non-cheap primop is duplicated In-Reply-To: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> References: <046.e8e92afd028064e60a5b451308a2b45b@haskell.org> Message-ID: <061.fd41473658a7f8ad5a9417b0391e1cd3@haskell.org> #13996: Non-cheap primop is duplicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 19:49:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 19:49:44 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.a021303431e7456edf297e9f09ef6b63@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): What we're doing here smells an awful lot like what we're doing in the case-of-known-constructor transformation in `rebuildCase`. Rather than a known constructor, we're dealing with a known bottom. Would it make sense to move the bottom check there, or is that nonsense? I don't have a great sense of how all these pieces fit together yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 20:17:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 20:17:29 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.fc3282c20402cebdc7488b05ad27fa3d@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by nomeata): I believe the mistake is in `CoreLint` here. The question is: How can `CoreLint` know that `x_ap6` is both void and evaluated, hence cannot actually exist? Probably we just need to change the code {{{ do { checkL (not (exprIsHNF scrut)) (text "No alternatives for a case scrutinee in head-normal form:" <+> ppr scrut) ; checkWarnL scrut_diverges (text "No alternatives for a case scrutinee not known to diverge for sure:" <+> ppr scrut) } }}} to something that runs the first check only when `scrut_diverges` is false (if `scrut_diverges`, then it cannot be in normal form). Or find out why `exprIsHNF scrut` is `True` here. Or maybe the outer `case` of {{{ case ds_dUn of { Foo x_ap6 -> case x_ap6 of { } } }}} should be empty, as the pattern `Foo x` is already absurd (due to the bang). Many options :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 20:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 20:17:54 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.f2d2273f49c54dc7a9eb403f5f24e7e9@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise 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: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: crockeea (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 20:40:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 20:40:10 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.2ae919a2cbabb9ea4d443494d8ffb27c@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: mpickering (added) Comment: I'm just getting back to looking at this. Since we don't have a record of the problematic `skylighting` version, let's go with the guess that this is the issue reported as [https://github.com/jgm/skylighting/issues/7 skylighting issue #7]. That is, that `skylighting-0.1.1.5` compiles slowly. There is further discussion of the problem in [https://github.com/jgm/texmath/issues/96 texmath issue #96]. mpickering was involved in those discussions; I don't know how much he knows/remembers. Their conclusion was that very large static data can take a long time to compile, for some reason. This whole thing sounds very familiar somehow; wasn't there some recentish work on handling ticks better for long list literals or some such? The package worked around this problem in [https://github.com/jgm/skylighting/commit/851bdd1e210ddecb00ceeffcabd9bf1fdc17b60e Skylighting.Syntax.*: use string representation of the Syntax] which simply used `read` to read a `String` representation of the data. Later, they [https://github.com/jgm/skylighting/commit/90ae0d0c23b7f8b218ff01152a912e374245aa5a switched to Binary]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 20:40:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 20:40:28 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.f9c45421fc9088ebf0b6e180e52c2937@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by nomeata): The cleanest solution might be: * extend `CoreUtils.filterAlts` to filter out impossible alternatives, i.e. constructors with fields with an empty type and a bang pattern. This code already filters out constructors that are impossible for other reasons. * extend `CoreLint` to not complain when a `case` is empty for this particular reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 21:07:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 21:07:39 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.de059daaf23d1951ac0c18f4691d3853@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * status: new => patch * milestone: => 8.2.1 Comment: I found the issue. I neglected to consider that the stack-pointer adjustment in the `AP_STACK` entry code also accounted for the words that we would later copy from the applied stack to the current thread's stack. Since the stack-pointer adjustment happened before we attempted to blackhole the `AP_STACK` closure, there was a small chance that we would suspend the thread with uninitialized content on its stack (specifically, if another thread beat us to blackholing the closure). This should be fixed by Phab:D3760. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 21:56:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 21:56:24 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.20d61a4d3bc52c9d22bdce2fb501409e@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Or find out why exprIsHNF scrut is True here. It's because in a case alternative {{{ K x -> ...x... }}} where `K` is strict, we know that when we unpack `K x`, the field `x` must be evaluated. So it is marked as such, and hence responds True to `exprIsHNF`. Joachim's solition is right; but it's very much a corner case and a bit hard to get right. E.g. {{{ data T a = T1 !(F a) Int | ... }}} When we pattern match on `T1 x y :: T X`, is that pattern impossible? WEll it depends on whether `(F X)` evaluates to an empty type. Hard to be sure it is fully nailed. Better, I think, to say that {{{ case x of {} }}} is fine if `x :: T` where `T` has no data constructors. That would silence the warning and is obviously correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 22:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 22:34:37 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.a5f98fa2cdfe9269e128676dcdc2a331@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I differ right at the start! If you look at the corresponding code for term variables you'll see (in `CoreSubst`): {{{ lookupIdSubst :: SDoc -> Subst -> Id -> CoreExpr lookupIdSubst doc (Subst in_scope ids _ _) v | not (isLocalId v) = Var v | Just e <- lookupVarEnv ids v = e | Just v' <- lookupInScope in_scope v = Var v' -- Vital! See Note [Extending the Subst] | otherwise = WARN( True, text "CoreSubst.lookupIdSubst" <+> doc <+> ppr v $$ ppr in_scope) Var v }}} We do ''not'' apply the substition to the type of the `Id` and update its type! Rather, we just look it up in the in-scope set: that should include all in-scope `Id`s; and moreover they are all full-substituted `OutIds`. A consequence is that all occurrences of the `Id` are common'd up to point to a single `Id` data structure, rather than having lots of copies of the `Id`. We should do the same for types. In `substTyVar`, if the var isn't in the `tenv` look in the in-scope set. It should be there. Of course, because we have not yet made all calls to `substTy` have the right in-scope set, we may not find it in the in-scope set. I suppose we can emit a warning, or just silently accept (as of course we are doing right now). Once we've fixed all the calls to `substTy` we should definitely make it a warning. So it's an easy fix. Did you say you'd found other lurking bugs as a result? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 22:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 22:47:52 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.0457290ce8130b60df8969ba1cbfcff2@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Who arranges for the members of the in-scope set to have substituted kinds? It's not uncommon to start a substitution with some in-scope set (derived from a call to `tyCoVarsOfTypes` or similar) and then build it from there. No one touches the in-scope set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 22:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 22:49:34 -0000 Subject: [GHC] #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist In-Reply-To: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> References: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> Message-ID: <061.7e9ca0c0934761c95197f937312db2ef@haskell.org> #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3761 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3761 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:24:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:24:24 -0000 Subject: [GHC] #13899: Improve [-Wmissing-home-modules] error message In-Reply-To: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> References: <044.df49ba2605478e0a66697c9eebb1eedd@haskell.org> Message-ID: <059.e61678db8c544f190705cad6d709d7a1@haskell.org> #13899: Improve [-Wmissing-home-modules] error message -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3686 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` in 17bce7bccbc65058dc064acf1ef38a5466491c76. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:24:43 -0000 Subject: [GHC] #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 In-Reply-To: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> References: <050.58beffd9cec8040fa6d7baae57dd373c@haskell.org> Message-ID: <065.d2f706637ad89ad636561d60ab45323c@haskell.org> #13948: GHC incorrectly suggests a data constructor is in scope in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13568 | Differential Rev(s): Phab:D3719 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.2.2 => 8.2.1 Comment: Merged to `ghc-8.2` in fb46561900480b8d9659ab3e9f8590a9a38a69ea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:25:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:25:11 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.2f78942aa81389bb94b0f98380e8f0e5@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13810, #13739 | Differential Rev(s): Phab:D3449, Wiki Page: | Phab:D3694 -------------------------------------+------------------------------------- Comment (by bgamari): comment:33 merged to `ghc-8.2` in c23a84d58e348d51632dfcafff81a2c94abcab0b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:25:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:25:34 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.7d2fcee0eb60ebce348de8ce1ac9239d@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.1 Comment: Merged to `ghc-8.2` in ad49958c3b9328ef89535cc2f38026d6601a44c5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.85663ccb5c6c9bde69e6a55b21c2f745@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ed41a7413a45e11a9bad3aafcfb7ee3f26236e4/ghc" 1ed41a7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ed41a7413a45e11a9bad3aafcfb7ee3f26236e4" Fix links to SPJ’s papers (fixes #12578) This fixes #12578. Update links to SPJ's papers in following files: * compiler/coreSyn/CoreSyn.hs * docs/users_guide/using-optimisation.rst * docs/users_guide/parallel.rst * docs/users_guide/glasgow_exts.rst This commit is for ghc-8.2 branch. Test Plan: build Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12578 Differential Revision: https://phabricator.haskell.org/D3745 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.100d73a9c4a3a92250bd24bab1bddfe6@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 13722 Related Tickets: | Differential Rev(s): Phab:D3724 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a051b555e32d7d8a08472e36be4cb08716d6d8ad/ghc" a051b555/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a051b555e32d7d8a08472e36be4cb08716d6d8ad" testsuite: Ensure that hs_try_putmvar003 terminates Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: simonmar, rwbarton, thomie GHC Trac Issues: #13434 Differential Revision: https://phabricator.haskell.org/D3724 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.8fdef9bf2df0765e259192e2891da145@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c940e3b92f4527ca59fcae93f36c869de3e7ccb9/ghc" c940e3b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c940e3b92f4527ca59fcae93f36c869de3e7ccb9" dmdAnal: Ensure that ExnStr flag isn't dropped inappropriately This fixes #13977 and consequently #13615. Here an optimization in the demand analyser was too liberal, causing us to drop the ExnStr flag and consequently resulting in incorrect demand signatures. This manifested as a segmentation fault in #13615 as we incorrectly concluded that an application of catchRetry# would bottom. Specifically, we had orElse' :: STM a -> STM a -> STM a orElse' x = catchRetry# x y where y = {- some action -} Where the catchRetry# primop places a demand of on its first argument. However, due to #13977 the demand analyser would assign a demand of on the first argument of orElse'. Note the missing `x`. case orElse' bottomingAction anotherAction of { x -> Just x } being transformed to, case orElse' bottomingAction anotherAction of {} by the simplifier. This would naturally blow up when orElse' returned at runtime, causing the segmentation fault described in #13615. Test Plan: Validate, perhaps add a testcase Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13977, #13615 Differential Revision: https://phabricator.haskell.org/D3756 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.f4a4622795a3e6ee1ae45908d00eed7e@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3733 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c9e4c861c6855e03bd14b182d2173da559e98d85/ghc" c9e4c861/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9e4c861c6855e03bd14b182d2173da559e98d85" Allow visible type application for [] This amounts to a one-line change in `tcExpr`. I've added a Note to explain what is going on. This requires a separate change in the pattern-match checker to account for the fact that typechecked `[]` expressions become `ConLikeOut`s, not `ExplicitList`s. Test Plan: make test TEST=T13680 Reviewers: goldfire, mpickering, austin, bgamari Reviewed By: mpickering, bgamari Subscribers: rwbarton, thomie, goldfire GHC Trac Issues: #13680 Differential Revision: https://phabricator.haskell.org/D3733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: [GHC] #13983: Type synonym referred to as datatype in error message In-Reply-To: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> References: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> Message-ID: <065.481397065fbb2e43a1d73925bc9ad000@haskell.org> #13983: Type synonym referred to as datatype in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e3c901db7a624d030614113c51be5731d1ac862/ghc" 6e3c901d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e3c901db7a624d030614113c51be5731d1ac862" Fix #13983 by creating a TyConFlavour type, and using it An error message was referring to a type synonym as a datatype. Annoyingly, learning that the TyCon over which the error message is operating is actually a type synonym was previously impossible, since that code only had access to a TcTyCon, which doesn't retain any information about what sort of TyCon it is. To rectify this, I created a new TyConFlavour datatype, intended to capture roughly what sort of TyCon we're dealing with. I then performing the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and propagated this information through to the relevant error message. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13983 Differential Revision: https://phabricator.haskell.org/D3747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 19 23:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Jul 2017 23:29:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.93f52c90cb2063221f69c15bc7f193da@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c940e3b92f4527ca59fcae93f36c869de3e7ccb9/ghc" c940e3b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c940e3b92f4527ca59fcae93f36c869de3e7ccb9" dmdAnal: Ensure that ExnStr flag isn't dropped inappropriately This fixes #13977 and consequently #13615. Here an optimization in the demand analyser was too liberal, causing us to drop the ExnStr flag and consequently resulting in incorrect demand signatures. This manifested as a segmentation fault in #13615 as we incorrectly concluded that an application of catchRetry# would bottom. Specifically, we had orElse' :: STM a -> STM a -> STM a orElse' x = catchRetry# x y where y = {- some action -} Where the catchRetry# primop places a demand of on its first argument. However, due to #13977 the demand analyser would assign a demand of on the first argument of orElse'. Note the missing `x`. case orElse' bottomingAction anotherAction of { x -> Just x } being transformed to, case orElse' bottomingAction anotherAction of {} by the simplifier. This would naturally blow up when orElse' returned at runtime, causing the segmentation fault described in #13615. Test Plan: Validate, perhaps add a testcase Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13977, #13615 Differential Revision: https://phabricator.haskell.org/D3756 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 01:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 01:05:15 -0000 Subject: [GHC] #13999: Simple function not inlined within declaration marked NOINLINE Message-ID: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> #13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Keywords: Inlining | 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: -------------------------------------+------------------------------------- This seems so shallow that I feel like I must be missing something, but if I implement a function like {{{#!hs eq :: Bool -> Bool -> Bool eq x y = x == y {-# NOINLINE eq #-} }}} the boolean equality operator is not inlined in eq, even at -O2. The generated core is instead {{{#!hs eq = $fEqBool_$c== }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 02:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 02:11:04 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.4ec41d078c96ba263be4a1757f55c15e@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It turns out that the root cause was #13977, which was fixed by Phab:D3756. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 02:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 02:17:54 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.ceed50a59345270801b93c2216bce6c7@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | TypeFamilies, Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3759 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cc839c57ff9c80b50d39e8e2e66a18674bab3486/ghc" cc839c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc839c57ff9c80b50d39e8e2e66a18674bab3486" Typeable: Ensure that promoted data family instance tycons get bindings This fixes #13915, where the promoted tycons belonging to data family instances wouldn't get Typeable bindings, resulting in missing declarations. Test Plan: Validate with included testcases Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, RyanGlScott, rwbarton, thomie GHC Trac Issues: #13915 Differential Revision: https://phabricator.haskell.org/D3759 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 02:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 02:18:47 -0000 Subject: [GHC] #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance In-Reply-To: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> References: <050.484d035d04f99a3cfb8081774d983a61@haskell.org> Message-ID: <065.39d4d0029f72815ca684d87e3d583cde@haskell.org> #13915: GHC 8.2 regression: "Can't find interface-file declaration" for promoted data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: TypeInType, | TypeFamilies, Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3759 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 725249344e28a58d2d827f38e630d0506f4e49cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 02:29:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 02:29:41 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.6f7de2757b55e15bc4ec6a329f0195f1@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Comment:53 was actualling intended to refer to #13916. Too many bugs with too similar numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 02:30:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 02:30:49 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.b2527a95f1d9670b5229398979bf6cbd@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to master with c940e3b92f4527ca59fcae93f36c869de3e7ccb9, {{{ dmdAnal: Ensure that ExnStr flag isn't dropped inappropriately This fixes #13977 and consequently #13615. Here an optimization in the demand analyser was too liberal, causing us to drop the ExnStr flag and consequently resulting in incorrect demand signatures. This manifested as a segmentation fault in #13615 as we incorrectly concluded that an application of catchRetry# would bottom. Specifically, we had orElse' :: STM a -> STM a -> STM a orElse' x = catchRetry# x y where y = {- some action -} Where the catchRetry# primop places a demand of on its first argument. However, due to #13977 the demand analyser would assign a demand of on the first argument of orElse'. Note the missing `x`. case orElse' bottomingAction anotherAction of { x -> Just x } being transformed to, case orElse' bottomingAction anotherAction of {} by the simplifier. This would naturally blow up when orElse' returned at runtime, causing the segmentation fault described in #13615. Test Plan: Validate, perhaps add a testcase Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13977, #13615 Differential Revision: https://phabricator.haskell.org/D3756 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 03:04:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 03:04:24 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.4e8a14124ed49cecfbb6bccd65b4e3e7@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 winter): I'm not sure if only the 10m runtimes were large enough to be meaningful, the problems is that for large files, we indeed spend more time on read and write instead of FFI scheduling, and unsafe FFI's blocking behaviour is indeed bad in this case. The different size of test is really supposed to test how different strategy react to each kind of workload, but i may have been failed to do that in that test though. FYI, currently in base we always do an unsafe read/write before call threadWaitRead/Write on *nix system, and since disk file never block, this is simply same as issue an unsafe call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 03:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 03:34:53 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.4aa39a5041aef2c725bfe39e82dd3595@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 13722 Related Tickets: | Differential Rev(s): Phab:D3724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: Merging to `ghc-8.2` as well to ensure clean validation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 03:35:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 03:35:35 -0000 Subject: [GHC] #13680: Can't use TypeApplications with [] data constructor In-Reply-To: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> References: <050.c0d4ac8e4bffb622e3af6a2ccf399ea9@haskell.org> Message-ID: <065.2c0dfab6bda7bb0ee1b516fe03f8adbe@haskell.org> #13680: Can't use TypeApplications with [] data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 03:36:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 03:36:02 -0000 Subject: [GHC] #13983: Type synonym referred to as datatype in error message In-Reply-To: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> References: <050.80426adcbbd0bbbee31f06874210f9c8@haskell.org> Message-ID: <065.cec6331949aaa68bc0e4f0bfbf4987a6@haskell.org> #13983: Type synonym referred to as datatype in error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 08:35:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 08:35:29 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.fa0b80f5b6e3327751397a77806598d7@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Who arranges for the members of the in-scope set to have substituted kinds? Well, if the in-scope set comes from the context (as in the simplifier or other places) all the `Var`s in the in-scope set are `OutIds`; that is, fully substituted. It would be wrong to substitute again, because it's entirely OK to have a substitution that goes `a :-> [a]`, because the LHS is `InVars` and the RHS is `OutVaers`. (This is not true during unification of course, but that's entirely separate.) E.g. a substitution [a :-> Proxy k (b::k), k :-> *] really means "replace `a` by `Proxy k (b::k)`" and NOT "then apply the subsituton to the result to get `Proxy * (b::*)`. No no no. Substitutions apply exactly once. (In this example the `k` in `Proxy k (b::k)` is an `OutTyVar` whereas the `k` in `k :-> *` is an `InTyVar`.) What if we build the in-scope set by taking the free vars of the range of the substitution? Eg. {{{ Substitute [a :-> Proxy k (b::k)] in the type (a, b) }}} The in-scope set, from the range of the substitution, is {b,k}. Do we need to apply the substitution to {b}? No! The range of the substitution is `OutVars` so we must not apply the substitution to it. A more delicate point is this: what if we build (part of) the in-scope set by taking the free vars of the type being substituted (see `substTyAddInScope` and `Note [The substitution invariant]` in`TyCoRep`? That's an `InType`! eg {{{ Substitute [a :-> Int] in the type (a, b::k) }}} Now we get an in-scope set of `{b::k}`. But although `b` appears in an `InType`, it must be an `OutTyVar` precisely because it is not substituted. It must be bound somewhere outside, and it'd be wrong to substitute its kind at one of its occurrences and not at its binding site! So I think everything is fine. But I really wish I had a clearer way to explain WHY it is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 08:37:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 08:37:56 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.15105471949d6161143d11197c7406e1@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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 simonpj): Do we have a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 08:50:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 08:50:35 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope Message-ID: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a c :: a -> T a main = c noSuchThing }}} yields: {{{ test_bad_error.hs:6:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a }}} This makes simple out-of-scope error seem very perplexing and is a huge regression in error quality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 09:54:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 09:54:12 -0000 Subject: [GHC] #13999: Simple function not inlined within declaration marked NOINLINE In-Reply-To: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> References: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> Message-ID: <057.098bce7a1cfe9dc34bed5223e73c0fd2@haskell.org> #13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by mpickering): Without the `NOINLINE` pragma the optimised definition is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 10:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 10:38:25 -0000 Subject: [GHC] #13999: Simple function not inlined within declaration marked NOINLINE In-Reply-To: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> References: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> Message-ID: <057.87831fbc1abf5c131d2fb72fa9a72724@haskell.org> #13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by srb): Well yes, but without NOINLINE it is likely that eq will be inlined in its caller, so delaying the inlining of (==) is arguably justifiable as a means to avoid excessive bloat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 11:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 11:42:46 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.b89ccc6b02e89b2183a9e4a3ee32b75d@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by mbieleck): Replying to [comment:7 simonpj]: > Better, I think, to say that > {{{ > case x of {} > }}} > is fine if `x :: T` where `T` has no data constructors. That would silence the warning and is obviously correct. Unfortunately that wouldn't fix my original problem. I encountered Core Lint errors when using [https://github.com/cdepillabout/servant-checked- exceptions/blob/master/src/Servant/Checked/Exceptions/Internal/Union.hs#L152 Servant.Checked.Exceptions.Internal.Union.absurdUnion]. Here the type involved is a GADT which __does__ have data constructors, but none of them matches the type parameter `'[]`. For the purposes of simplifying the test case I replaced it with `Void`, since they are isomorphic, but it makes a difference when linting. Here's a test case better reflecting the situation: {{{#!hs {-# LANGUAGE EmptyCase, GADTs #-} module Bug where data T a where TInt :: T Int absurd :: T Bool -> a absurd v = case v of {} data Foo = Foo !(T Bool) absurdFoo :: Foo -> a absurdFoo (Foo x) = absurd x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 12:34:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 12:34:52 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.bbe548172bb9ed1e891ed3a53eb9dba2@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` with 26f839f457ce1bf1a940a12e45c8137621ce1378. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 12:35:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 12:35:36 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.a8def844fcd1d12231f3fcdb5247eae5@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: fixed | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.2.2 => 8.2.1 Comment: Merged to `ghc-8.2` with 26f839f457ce1bf1a940a12e45c8137621ce1378 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 13:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 13:13:42 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.3dc493fb05fa53dbcd0cd1a21b5a332b@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * differential: => D3763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 13:37:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 13:37:26 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.741692e3763049d82d7a9901593e849a@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3763 Wiki Page: | -------------------------------------+------------------------------------- Comment (by supersven): I'm now running this build .mk (`make -j4`) {{{ SRC_HC_OPTS = -O0 -H64m GhcStage1HcOpts = -O0 GhcStage2HcOpts = -O0 GhcLibHcOpts = -O0 BUILD_PROF_LIBS = NO SplitObjs = NO SplitSections = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} to make sure nothing breaks without optimization (-O0 -> no optimization). My machine config (output of `./configure`): {{{ ---------------------------------------------------------------------- Configure completed successfully. Building GHC version : 8.3.20170720 Git commit id : fa28ec2927e905228283708d6dcc194e4f65d49c Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /usr/bin/ghc which is version : 8.0.2 Using (for bootstrapping) : /usr/bin/gcc Using gcc : gcc which is version : 6.3.0 Building a cross compiler : NO Unregisterised : NO hs-cpp : gcc hs-cpp-flags : -E -undef -traditional ar : ar ld : ld.gold nm : nm libtool : objdump : ranlib : ranlib windres : dllwrap : Happy : /usr/bin/happy (1.19.5) Alex : /usr/bin/alex (3.1.7) Perl : /usr/bin/perl sphinx-build : /usr/local/bin/sphinx-build xelatex : /usr/bin/xelatex Using LLVM tools llc : opt : HsColour : /usr/bin/HsColour Tools to build Sphinx HTML documentation available: YES Tools to build Sphinx PDF documentation available: YES ---------------------------------------------------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 14:23:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 14:23:53 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.d11ab09a60afbf8323e07a8f161deee4@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): After a long debate, Simon and I came up with the following claim: '''(*) Claim''': If a tyvar is not in the domain of a substitution, then no variables in its kind are in the domain of a substitution. If (*) is true, then the change Phab:D3732 should be a no-op: precisely no behavior should change. And we can check (*) on the fly, which we should. Why should (*) be true? Here's some rough reasoning: a tyvar `a` whose kind mentions `k` must be bound in `k`'s scope. If we are substituting `k` (to `Type`, say), then we'll need to substitute both in `a`'s binding site and `a`'s scope. When we subst in the binding site (with `substTyVarBndr`), the subst is extended mapping `a:k` to `a:Type`; `a` is thus in the domain of the subst when we get to substing in `a`'s scope. If we've forgotten to call `substTyVarBndr`, then we're in deep trouble, anyway. Thus, all tyvars whose kinds mention `k` will be added to the subst by the time we get to their scope. But thinking about (*) led us to ponder this strange scenario: `forall k. forall (b :: k). forall k. forall (a :: k). Proxy [a,b]`. Is that well- kinded? Surely not, because `a` and `b` have different kinds: `a`'s kind is the more local `k` while `b`'s kind is the less local `k`. However, Core Lint is going to have a hard time with this. When Lint looks at `[a,b]`, it will ask for `a`'s kind and get `k`. It will ask for `b`'s kind and get `k`. And the `k`s will be equal! Core Lint will accept. This is horrible. This bug may have been lurking in GHC for ages. The remedy: don't do this. Specifically, we introduce '''(+) Rule''': When a tyvar `a` is brought into scope, all vars (type and term) whose type mentions `a` fall out of scope. Under (+), `b` is not in scope in `[a,b]` and we have a straightforward scoping error. We can check this in Lint. We couldn't quite convince ourselves that (+) is actually always respected during transformations, etc., but by adding a rule in Lint, we can discover when it doesn't. An alternative to (+) is (-) Rule: It is illegal to shadow a variable. That is, if `a` is in scope, we cannot bind `a`. (-) implies (+) and is easy to check for. However, it may not be so easy to uphold; Simon claims several places in GHC knowingly violate (-), and avoiding this violation may hurt performance. I'm worried that any code that violates (-) will sometimes fall afoul of (+) (but only in very obscure scenarios). Simon claims that the violations of (-) but not (+) involve closed types and therefore are safe w.r.t. (+). So we've agreed to check for (+) for now and see how that goes. As a sidenote: comment:7 and comment:9 concern term-level substitutions. At the term level, we have a real interest in commoning up occurrences (so that all occurrences of an Id `x` actually point to the same heap object) because of `IdInfo`. In types, on the other hand, we have an interest in avoiding forcing a `TCvSubst`'s `InScopeSet`, and so we don't use the same "look up in in-scope set" approach. So, essentially, comment:7 and comment:9 are red herrings. == Bottom line == We have these tasks: 1. Check for (*) in `substTyVar`. This is instead of the kind substitution discussed earlier in this ticket. Document (*). 2. Update Core Lint to check (+). Document (+) in a nice Note. 3. (Optional) If we blindly set `no_kind_change` to `False` in `substTyVarBndrCallback`, then substitutions ''will'' common up type variables by looking up type variables in the substitution. There's a chance this will have a performance benefit. Try and investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 14:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 14:49:19 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.2f3ca313e05b976156abdabde28a43ec@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3732 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to add: Rule (+) means that the following program is illegal: {{{ forall (k:*). forall (a:k). forall (k:*->*). a }}} Note the shadowing: there are really two k's. It's illegal according to (+) because bringing the inner `k` into scope makes `a` (as well as the outer `k`) fall out of scope, because `a`'s kind mentions `k`. Why this rule? Because in the implementation we have kinds on every variable occurrence, and the kind on an occurrence should match that on the binder. So {{{ forall (a:*). (a:*) -> Int }}} is fine, but {{{ forall (a:*). T (a:*->*) }}} is not, because the kind on `a`'s occurrence doesn't match that at its binding site. And Rule (+) makes this illegal too: {{{ forall (k:*). forall (a:k). forall (k:*->*). (a:k) }}} because the kind at `a`'s occurrence is a different `k` to that at its binding site. Another way to say it is that `typeKind` (and `exprType`) yield sane results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 15:02:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 15:02:57 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.5e02439c7ba53934f85aeb464067ad83@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 15:08:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 15:08:17 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.2645e4ac03e0e2b4caa45e6dfa293ed2@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. Let's stand back a bit. * The simplifier (via `CoreSyn.filterAlts`) can eliminate branches of a case that can't happen, because of (a) GADT matching and (b) lexically enclosing case expressions. * Lint can't guarantee to come to the same conclusion becuase of floating. Eg {{{ data T = A | B | C f x = case x of A -> e1 _ -> ...(case x of B -> e1 C -> e3)... ===> f x = let t = case x of B -> e1 C -> e3 in case x of A -> e1 _ -> ...t... }}} Before, it's clear that the inner case is exhaustive, but not so clear after the transformation. * So currently Lint doesn't attempt to complain about inexhaustive cases. * EXCEPT if there are zero alternatives. And for that, strangely, Lint makes two separate checks. First, in the `Case` equation for `lintCoreExpr`: {{{ -- See Note [No alternatives lint check] ; when (null alts) $ do { checkL (not (exprIsHNF scrut)) (text "No alternatives for a case scrutinee in head-normal form:" <+> ppr scrut) ; checkWarnL scrut_diverges (text "No alternatives for a case scrutinee not known to diverge for sure:" <+> ppr scrut) } }}} Second in `checkCaseAlts`: {{{ ; checkL (isJust maybe_deflt || not is_infinite_ty || null alts) (nonExhaustiveAltsMsg e) } }}} Clearly we should do this stuff in only one place. I now propose that we remove the "null alts" check altogether. It's just an extreme case of having filtered out all alternatives. The current code treats it specially, but this ticket has convinced me that it's not special afte all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 15:18:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 15:18:09 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.b23124fbbad01fa56bba1ee933aa92ef@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D3732 => Comment: Removing abandoned Diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 15:38:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 15:38:11 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.d0daa5124528bd7692440127b065eee2@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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 bgamari): Do you mean for #13977? I intend on adding the case from #13916 to the testsuite. It's imperfect but better than nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 15:41:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 15:41:06 -0000 Subject: [GHC] #14001: Inlining does not work between modules Message-ID: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Hi! I discovered today something that looks like a terrifying bug. I was discussing it on IRC and so far there is no explanation why it happens. Let's grab a test code from here: https://github.com/luna/dependent- state/tree/irc-testing (branch irc-testing). If you download it and execute `stack --stack-yaml stack-develop.yaml bench dependent-state:layered-state-benchmark` benchmarks from `test/bench/Main.hs` will be executed. Everything is compiled with `-O2` etc (see stack-develop.yaml for details). And now (everything regarding file `Control/Monad/State/Layered.hs`): 1. If you change lines `94-111` to use pointfree instead of normal arg, you get 40x slowdown 2. If you then uncomment lines `80-81`, everything is fast again. The problem is that lines `80-81` are: {{{ (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} }}} It seems that this function is inlined ONLY if is defined in this module. If we use the one from base OR if we move this function to separate module, we can observe the slowdown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:02:23 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.404f9eb456addacc23c02555c88770e7@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * failure: None/Unknown => Poor/confusing error message * keywords: => TypeFamilies Comment: Indeed, the error message in GHC 7.10.3 and earlier was simply: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:5:10: Not in scope: ‘noSuchThing’ Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13987: T13701 fails sporadically In-Reply-To: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> References: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> Message-ID: <058.82b06868e2cf11d58e021f31a4788609@haskell.org> #13987: T13701 fails sporadically -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3748 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"194384f1318e0553e0c5ce621ca0903b55862eb3/ghc" 194384f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="194384f1318e0553e0c5ce621ca0903b55862eb3" Fix busy-wait in SysTools.builderMainLoop Test T13701 was failing sporadically. The problem manifested while the test was run on a system under load. Profiling showed the increased allocations were in SysTools.builderMainLoop.loop, during calls to the assembler. This was due to loop effectively busy-waiting from when both stdin and stderr handles were closed, until getProcessExitCode succeeded. This is fixed by removing exit code handling from loop. We now wait for loop to finish, then read the exit code with waitForProcess. Some exception safety is added: the readerProc threads will now be killed and the handles will be closed if an exception is thrown. A TODO saying that threads dying is not accounted for is removed. I believe that this case is handled by readerProc sending EOF in a finally clause. Test Plan: Replicate test failures using procedure on the ticket, verify that they do not occur with this patch. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13987 Differential Revision: https://phabricator.haskell.org/D3748 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.b4732fab7c692cecf84124c69aa238a5@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 Ben Gamari ): In [changeset:"fdb6a5bfd545094782fb539951b561ac2467443d/ghc" fdb6a5b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fdb6a5bfd545094782fb539951b561ac2467443d" Make IfaceAxiom typechecking lazier. Fixes #13803, but adds a note about a yet to be fixed #13981. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13803 Differential Revision: https://phabricator.haskell.org/D3742 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.5fd6949417f66553983c80f17489c157@haskell.org> References: <044.5fd6949417f66553983c80f17489c157@haskell.org> Message-ID: <059.cd953e5aa87bcb76b6b92dbe08e36f93@haskell.org> #13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3742 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fdb6a5bfd545094782fb539951b561ac2467443d/ghc" fdb6a5b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fdb6a5bfd545094782fb539951b561ac2467443d" Make IfaceAxiom typechecking lazier. Fixes #13803, but adds a note about a yet to be fixed #13981. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13803 Differential Revision: https://phabricator.haskell.org/D3742 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13825: Allow multiple constructor fields occupy the same word In-Reply-To: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> References: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> Message-ID: <061.a5dce74aecb30adbe7bfcf4ab7ed3ed2@haskell.org> #13825: Allow multiple constructor fields occupy the same word -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #605 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5469ac86f9cc9e83b93ed34ca13f0a4f58f4a9a6/ghc" 5469ac86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5469ac86f9cc9e83b93ed34ca13f0a4f58f4a9a6" Interpreter.c: use macros to access/modify Sp This is another step in fixing #13825 (based on D38 by Simon Marlow). This commit adds a few macros for accessing and modifying `Sp` (interpreter stack) and will be useful to allow sub-word indexing/pushing. (but that will be a separate change, this commit should introduce no changes in behavior) Signed-off-by: Michal Terepeta Test Plan: ./validate Reviewers: bgamari, simonmar, austin, erikd Reviewed By: bgamari, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3744 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist In-Reply-To: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> References: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> Message-ID: <061.ea009f813d5992e687b46f22a296404b@haskell.org> #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3761 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1480080b31e9f7cd47ca7b677455b3558b0da2bc/ghc" 1480080/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1480080b31e9f7cd47ca7b677455b3558b0da2bc" distrib/configure: Canonicalize triples Previously we failed to do this, which meant that the bindist's configure would fail when passed --target (as you may need to do when installing an armv7 bindist on an aarch64 machine, for instance). Reviewers: hvr, erikd, austin Reviewed By: hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13934 Differential Revision: https://phabricator.haskell.org/D3761 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.403d7d643d14a4bbe18cccb25ace7762@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bade356f79d44c9f6e8918a89d9ffac7f5608dbf/ghc" bade356/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bade356f79d44c9f6e8918a89d9ffac7f5608dbf" rts: Claim AP_STACK before adjusting Sp In the fix to #13615 we introduced some logic to atomically blackhole AP_STACKs closures upon entry. However, this logic was placed *after* a stack pointer adjustment. This meant that if someone else beat us to blackholing the AP_STACK we would suspend the thread with uninitialized content on the stack. This would then later blow up when threadPaused attempted to walk the stack, hence #13970. Silly bug but still cost lots of head-scratching to find. Thanks to albertov for the great repro. Fixes #13970. Bug originally introduced by the fix to #13615. Reviewers: austin, erikd, simonmar Reviewed By: erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13970, #13615 Differential Revision: https://phabricator.haskell.org/D3760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.6302fb5692c01b1cb9ce58a5baedfdfc@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: fixed | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b2d3ec370b97fe5f448e8f1d4e0b7374c63c60a8/ghc" b2d3ec37/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2d3ec370b97fe5f448e8f1d4e0b7374c63c60a8" testsuite: Add test for #13916 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:04:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:04:52 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.2a15123fc32811dcdd2daac7c39fa3fb@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 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 Ben Gamari ): In [changeset:"bade356f79d44c9f6e8918a89d9ffac7f5608dbf/ghc" bade356/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bade356f79d44c9f6e8918a89d9ffac7f5608dbf" rts: Claim AP_STACK before adjusting Sp In the fix to #13615 we introduced some logic to atomically blackhole AP_STACKs closures upon entry. However, this logic was placed *after* a stack pointer adjustment. This meant that if someone else beat us to blackholing the AP_STACK we would suspend the thread with uninitialized content on the stack. This would then later blow up when threadPaused attempted to walk the stack, hence #13970. Silly bug but still cost lots of head-scratching to find. Thanks to albertov for the great repro. Fixes #13970. Bug originally introduced by the fix to #13615. Reviewers: austin, erikd, simonmar Reviewed By: erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13970, #13615 Differential Revision: https://phabricator.haskell.org/D3760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:06:20 -0000 Subject: [GHC] #13916: Optimizations create run time seg faults In-Reply-To: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> References: <046.033688a2825b9b8f78d42e15efe42995@haskell.org> Message-ID: <061.8b41bf1f0290ed77c04a3171178df0c3@haskell.org> #13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: fixed | Keywords: optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ccac387bd90da8e1b6998e8480897a0bf0694310/ghc" ccac387b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ccac387bd90da8e1b6998e8480897a0bf0694310" Revert "testsuite: Add test for #13916" This reverts commit b2d3ec370b97fe5f448e8f1d4e0b7374c63c60a8. Didn't mean to push this one. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:09:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:09:18 -0000 Subject: [GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.5fd6949417f66553983c80f17489c157@haskell.org> References: <044.5fd6949417f66553983c80f17489c157@haskell.org> Message-ID: <059.a64a5fc7d5b710dbcdb706790b3d2916@haskell.org> #13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3742 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.1 Comment: It looks like we'll want to merge this for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:09:39 -0000 Subject: [GHC] #13987: T13701 fails sporadically In-Reply-To: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> References: <043.0582c43a550d7fe91ecfd266562cd2ed@haskell.org> Message-ID: <058.b442d87d302c932e6a851237975b4642@haskell.org> #13987: T13701 fails sporadically -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:27:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:27:32 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.d11388ea616aa724d325600649c6595e@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 j.waldmann): This might also depend on the (perceived) arity of the function, cf. comp1/comp2 in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #inline-pragma -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:32:12 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.7369910ed4c75897966c17559fba8209@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, I tried a random commit from before GHC 8.0.1 (707b2be97539b83efb91cd9f17f94c91397ad2b4), and I received more information in the error messages: {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:5:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a ../Bug.hs:5:10: error: Variable not in scope: noSuchThing }}} So at separate commits, GHC (1) started complaining about this `Couldn't match expected type` business (which is questionable), and (2) stopped complaining about `noSuchThing` not being in scope (which is definitely wrong). I've yet to figure out which commits are responsible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:36:05 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.43e76e12d9e037f6f85e86bc412d9126@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 danilo2): @j.waldman I dont think so. It does not explain why `(.)` function in this module is faster than EXACTLY the same implementation in other module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:43:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:43:08 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.2c86a738dcc2706b74f192a362192a1f@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 simonpj): Is it possible to make a smaller test case? Just a couple of modules, showing where `(.)` is not inlined? (No need to make it a runnable benchmark.) Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:43:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:43:56 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.0bba5d1237dc7050f8ed89648ffcf11e@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Let me think about a better way. Still thinking (turned out to have ramifications). Work on something else for now! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:50:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:50:26 -0000 Subject: [GHC] #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist In-Reply-To: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> References: <046.3931a0d9240dd1d19bffe15fe6728d48@haskell.org> Message-ID: <061.4c50a8e05c14f07c35857be09b1efca4@haskell.org> #13934: FP_CONVERT_CPU fails to convert CPU when invoked from bindist -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3761 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with e86ebd4f35a3d55db8855a31fa8c9bd6971dcafc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:50:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:50:48 -0000 Subject: [GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.5fd6949417f66553983c80f17489c157@haskell.org> References: <044.5fd6949417f66553983c80f17489c157@haskell.org> Message-ID: <059.4869175768316e6872faec7b6a584efc@haskell.org> #13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: hs-boot 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): Phab:D3742 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with 31c5c7c5ba8587d6e06782c260db1b3313a05df6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:51:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:51:39 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.472810847415bd572402f1dd4b5d60aa@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with ffea6cfe7137093c32cd2357fb9fdf9db9430543. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 16:51:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 16:51:58 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.32db3d61f1543785a971690fe597d767@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 danilo2): Simon, this use case has 2 files - one with definition of StateT wrapper and the second with benchmark. There are 2 other files but completely commented out, sorry for not removing them. I was cleaning in hurry to discuss it on IRC. Anyway there are two source files: 1. Control/Monad/State/Layered.hs - StateT newtype wrapper 2. test/bench/Main.hs - couple lines of benchmarks showing the slowdown Is it good enough ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 17:04:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 17:04:25 -0000 Subject: [GHC] #13805: GHC 8.0.2 fails to build on macOS 10.13/Xcode 9 - preprocessor error in ghc-pkg In-Reply-To: <049.5c553f223a194e22fdf785f7cd8ea0f5@haskell.org> References: <049.5c553f223a194e22fdf785f7cd8ea0f5@haskell.org> Message-ID: <064.27954a149c5bb6c586a3a941f22b5503@haskell.org> #13805: GHC 8.0.2 fails to build on macOS 10.13/Xcode 9 - preprocessor error in ghc-pkg -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mistydemeo): * status: new => closed * resolution: => fixed Comment: Resolved with an upstream fix in clang: https://bugs.llvm.org/show_bug.cgi?id=33394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 17:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 17:44:02 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.8c7ab9f8c4c8b20d3a7ed40470c30f47@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.0.1 => 8.0.2 Comment: Actually, the `Couldn't match expected type` error was dropped somewhere between 8.0.1 and 8.0.2, since in 8.0.1, you get: {{{ $ /opt/ghc/8.0.1/bin/ghci ../Bug.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:5:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a ../Bug.hs:5:10: error: Variable not in scope: noSuchThing }}} But in GHC 8.0.2: {{{ $ /opt/ghc/8.0.2/bin/ghci ../Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:5:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 17:47:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 17:47:34 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.b12ab5f9ec1010b0ada92ba494e3bcb0@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 mpickering): I managed to reproduce this. Working to produce a smaller example now but the core is certainly different in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:00:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:00:38 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.341cfcf38c5e8f85977974b901f31ab1@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Old description: > This is a follow up ticket for #13803, since I wanted to fix the > immediate bug in #13803 without having to deal with the more complicated > case here: > > {{{ > -- F.hs > {-# LANGUAGE TypeFamilies #-} > module F where > type family F a :: * > > -- A.hs-boot > module A where > data T > > -- B.hs > {-# LANGUAGE TypeFamilies #-} > module B where > import {-# SOURCE #-} A > import F > type instance F T = Int > > -- C.hs > {-# LANGUAGE TypeFamilies #-} > module C where > import {-# SOURCE #-} A > import F > type instance F T = Bool > > -- A.hs > module A where > import B > import C > > data T = T > }}} > > From what I wrote: right now, we decide to defer a type family > consistency check if the family was recursively defined. If the RHS > refers to a recursively defined type, there's no problem: we don't need > to look at it for consistency checking. But if the LHS is recursively > defined, as is in this example, we DO need to defer the check. > > But it's a bit irritating to figure out whether or not there's actually a > reference to a recursively defined type in the LHS, since this involves > traversing the LHS types, and if we're not careful we'll end up pulling > in the TyThing anyway. There are two other possibilities: (1) always > defer checking instances which are defined inside the recursive look (by > looking at the Name of the axiom), or (2) annotating IfaceAxiom with the > set of boot types its LHS refers to, for easy checking. Not entirely sure > what the best action is. New description: This is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here: {{{#!hs -- F.hs {-# LANGUAGE TypeFamilies #-} module F where type family F a :: * -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A import F type instance F T = Int -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import {-# SOURCE #-} A import F type instance F T = Bool -- A.hs module A where import B import C data T = T }}} From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check. But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is. -- Comment: Merged to `ghc-8.2` with 31c5c7c5ba8587d6e06782c260db1b3313a05df6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:07:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:07:07 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.3a8aba4fc6192f6fd42eb1a26da27c16@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think actually just passing `--format=posix` will be sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:12:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:12:54 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.6db5fa1344c78cd6f932783f037bc66f@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Phab:D3765 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3765 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:13:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:13:37 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.3afdeab398caa2a21c8e06f5b2225508@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Phab:D3754 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:15:09 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.6ade74bb4e053f311867e1f7d1274405@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: I'm afraid this won't be fixed for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:17:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:17:04 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.d28a8f4e7706b165cd9d8f7aa78dc97d@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I think it's reasonable to do the conservative thing here and just return `False` for splices for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:22:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:22:18 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.75be6f4e268dd83a1cc7de59c376c484@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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): Phab:D3766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:23:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:23:14 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.e1594df930fb28fe641433fcbfb65bf7@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: Given that `UndecidableInstances` is in play here I'm going to declare this non-release-critical and punt to 8.2.2 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:49:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:49:45 -0000 Subject: [GHC] #13993: Certain inter-module specializations run out of simplifier ticks In-Reply-To: <045.c6bc8515dbb94daa199675ba8f625d65@haskell.org> References: <045.c6bc8515dbb94daa199675ba8f625d65@haskell.org> Message-ID: <060.41146247105d270577be4bb45dc4ddd4@haskell.org> #13993: Certain inter-module specializations run out of simplifier ticks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 18:56:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 18:56:44 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.0cda4490f33898442d4be531d9589039@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I believe we can just pass the `--posix` flag to `gtar` to ensure that the resulting tarball is compatible with `bsdtar`. See Phab:D3765. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 19:54:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 19:54:30 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.795dd4fe571ba56a69ad1b8bd14dfcfe@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 mpickering): Here is a smaller reproduction. I don't think a lot of the type family stuff is necessary for the reproduction. https://github.com/mpickering/musical-spork You can build it with `cabal new-build`. I noticed that the `Strict` language extension was enabled and so the definitions were not in fact equivalent. This makes the performance difference less surprising. If you modify the definition of `(.)` in `A.hs` to remove the bang then the program gets a lot slower. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 19:59:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 19:59:20 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.e1e989fc98add390dbb9e6cc98b6459c@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: The `Variable not in scope` error was dropped in 5662ceaeb4da4fdee0f9fc01f72855168471377f (`Improve error handling in TcRnMonad`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 20:15:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 20:15:13 -0000 Subject: [GHC] #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file Message-ID: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- When defining a strict composition function in GHCi using {{{ let f .:. g = seq f (seq g (\x -> f (g x))) }}} (omitting the let makes no difference) and then executing {{{ seq (undefined .:. undefined) () }}} this evaluates to {{{()}}} instead of bottom as I would have expected. If {{{.:.}}} is defined an a file and then loaded in GHCi the same statement evaluates to bottom. This also holds when {{{.:.}}} is introduced via a let+in instead of a separate let statement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 21:00:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 21:00:47 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.4c79754d0ba96456cca2a38a94b80db8@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): > I'm not sure if only the 10m runtimes were large enough to be meaningful The benchmark when run against the `1m` input took less than 50 milliseconds. I doubt that this is enough for the benchmark to get into enough of a steady-state to be representative of actual performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 21:09:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 21:09:32 -0000 Subject: [GHC] #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file In-Reply-To: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> References: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> Message-ID: <064.c7323c7d15e5a4be6442c672d032fd33@haskell.org> #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 lspitzner): seems to start occurring at ghc-7.10. also curios that `let func f = seq f f` does not show this error, while `let func f = seq f (\x -> f x)` does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 21:20:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 21:20:14 -0000 Subject: [GHC] #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file In-Reply-To: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> References: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> Message-ID: <064.e3a96a352fcba2edaa8274a43af3f2ed@haskell.org> #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 sgraf): Similarly, `let flippedConst f = seq f (\x -> x)` will make `seq (flippedConst undefined) ()` return `()`, while `let flippedConst f = seq f id` will make it diverge. I expected divergence in both cases, btw. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 22:02:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 22:02:17 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.619276d73c2cec31f1f0836bdf7e891f@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The `Couldn't match expected type` error snuck in after fb7b6922573af76a954d939c85e6af7c39a19896 (`Treat out-of-scope variables as holes`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 22:13:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 22:13:03 -0000 Subject: [GHC] #13639: Skylighting package compilation is glacial In-Reply-To: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> References: <046.64388e0a2e512a976d78587b5b6b3aaa@haskell.org> Message-ID: <061.32d1557aad21074dd80427ef91374b2f@haskell.org> #13639: Skylighting package compilation is glacial -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In a recent HEAD ( 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98 ): The "nearly ten minutes" seems to be the "user" time in a parallel build, for which the real time is around 3 minutes. If cabal and GHC are each passed `-j1`, the user time drops to around five minutes. So one issue seems to be some inefficiency in parallel builds. Running single-threaded, I don't see any big difference between the time it takes to build the unprofiled and profiled versions (although of course building both takes about twice as long as building just the unprofiled). So I don't really think profiling has anything to do with the issue, at least for HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 23:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 23:04:39 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.23230d29edb571d4a5d94318866bc39f@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 simonpj): I'm confused. In Matthew's repro case, * Function `(.)` is defined in module `A` and not exported. * So far as I can see, it is inlined at all its call sites in `A`. * The comment says that adding a bang to one of `(.)`'s arguments makes a big perf difference. That does not sound like a bug to me. Can someone explain what the problem is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 23:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 23:07:54 -0000 Subject: [GHC] #13999: Simple function not inlined within declaration marked NOINLINE In-Reply-To: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> References: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> Message-ID: <057.93866f7fdac80852790c0cd5ef7e622c@haskell.org> #13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by simonpj): What's the problem here? YOu get the same code whether or not `eq` is marked `NOINLINE`. GHC generally doesn't inline a function if the caller cannot benefit, which it can't here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 23:13:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 23:13:03 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr Message-ID: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Keywords: JoinPoints, | Operating System: Unknown/Multiple Fusion | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code. Setting ```-fmax-worker-args=100``` leads to complete specialization again. However, given that code annotated with ```SPEC``` should be optimized until no more ```SPEC``` arguments are alive, shouldn't ```callToNewPats``` in ```compiler/specialise/SpecConstr.hs``` specialize *irrespective* of the size of the worker argument list? Code that actually fails to specialize is fairly large, hence no test case -- though I have some files with core output showing insufficient specialization. (I'd be willing to write a patch for this) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 23:24:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 23:24:23 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.bc2bf34d15bc4fd23763f5901cbaee8d@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: panic | template-haskell 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): Phab:D3766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"36e8bcba08446dbc4e7532ef9db5517c13977bf9/ghc" 36e8bcba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="36e8bcba08446dbc4e7532ef9db5517c13977bf9" HsPat: Assume that no spliced patterns are irrefutable This is a conservative assumption which will limit some uses of spliced patterns, but it fixes #13984. Test Plan: Validate Reviewers: RyanGlScott, AaronFriel, austin Reviewed By: RyanGlScott Subscribers: rwbarton, thomie GHC Trac Issues: #13984 Differential Revision: https://phabricator.haskell.org/D3766 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 20 23:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Jul 2017 23:29:55 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.be8c9f49a155c875a979896c4d90e958@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Phab:D3765 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, never mind. It has little to do with the tar file format. Rather, the files which failed in ticket:13974#comment:5 are all included multiple times in the bindist. For instance, {{{ $ tar -vtf ghc-8.3.20170720-x86_64-unknown-linux.tar.xz ... -rwxr-xr-x 0 ben ben 54184 Jul 20 20:45 ghc-8.3.20170720/utils/hp2ps/dist-install/build/tmp/hp2ps hrwxr-xr-x 0 ben ben 0 Jul 20 20:45 ghc-8.3.20170720/utils/hp2ps/dist-install/build/tmp/hp2ps link to ghc-8.3.20170720/utils/hp2ps/dist-install/build/tmp/hp2ps }}} This is no doubt due to a build system bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 01:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 01:16:50 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.49e06f2d995245b9cf2f18d9b8ab2708@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It turns out that I was totally wrong. See ticket:13979#comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 01:29:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 01:29:25 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.9a4d8acf8a4cd1a5bc8c2b87d57f1a0f@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Phab:D3767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3765 => Phab:D3767 Comment: Alright Make, you win. I spent a half an hour trying to work out where these duplicates were coming from. It seems like the `ifeq`s in `rules/build-prog.mk` aren't quite doing what we expect. Given that Hadrian is right around the corner I'm not terribly keen on sinking a bunch of time into this. Consequently, I propose the hack in Phab:D3767. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 01:31:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 01:31:55 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.e563d1fa0da98cc0b4c860fdd9a47a19@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See Phab:D3767 for a hack hopefully fixing the tar issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 01:41:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 01:41:50 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.8903db681c53cdc5429901083db445da@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Phab:D3754 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I'm afraid we're going to have to punt on this for 8.2.1. The patch is simply too large to merge this late in the game (especially since backports tend to be extra painful with the trees-that-grow change behind us). Perhaps we can make this happen for 8.2.2 if someone yells, but otherwise I would be tempted to simply wait for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:01:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:01:28 -0000 Subject: [GHC] #13977: ExnStr doesn't propagate "outwards" In-Reply-To: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> References: <046.cbba3f77d296e9035bb7a6da2157b242@haskell.org> Message-ID: <061.e52e33abcd6e46b0e32b4875a1324f92@haskell.org> #13977: ExnStr doesn't propagate "outwards" -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3756 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => Exceptions Comment: I believe this fix may bear on a number of tickets which have come up in the past year or so, * #13380: `raiseIO#` result looks wrong * #13330: `forkIO` has inconsistent behavior under optimization * #11555: `catch` _|_ breaks at `-O1` * #11222: Teach strictness analysis about `catch`-like operations * #13357: Check demand signatures for `catchRetry#` and `catchSTM#` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:04:44 -0000 Subject: [GHC] #14004: G Message-ID: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPING #-} Eq a => GEq a a where geq = (==) instance GEq a b where geq _ _ = False }}} {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq::a->b->Bool :3:1: Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ Matching instances: instance GEq a b -- Defined at GEq.hs:9:10 instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 (The choice depends on the instantiation of ‘a1, b1’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the expression: geq :: a -> b -> Bool In an equation for ‘it’: it = geq :: a -> b -> Bool *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:17:01 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.e9d4afeaf47f2bb9fe6f8add6d356c19@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Phab:D3767 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fefcbfa86b73517d5002366d0703ce694c6d228d/ghc" fefcbfa8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fefcbfa86b73517d5002366d0703ce694c6d228d" build system: Ensure there are no duplicate files in bindist list Several executables inexplicably appear twice in bindist.list, which ends up producing multiple tar file entries, consequently breaking BSD tar during extraction. I spent a fair amount of time trying to work out where these duplicates were coming from to no avail. Since Hadrian is right around the corner I'm satisfied with a terrible hack: just uniq bindist.list before producing the bindist tarball. Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13979, #13974 Differential Revision: https://phabricator.haskell.org/D3767 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:17:01 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.bd9a7ddb256f2218065fd9fbab9f0a37@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fefcbfa86b73517d5002366d0703ce694c6d228d/ghc" fefcbfa8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fefcbfa86b73517d5002366d0703ce694c6d228d" build system: Ensure there are no duplicate files in bindist list Several executables inexplicably appear twice in bindist.list, which ends up producing multiple tar file entries, consequently breaking BSD tar during extraction. I spent a fair amount of time trying to work out where these duplicates were coming from to no avail. Since Hadrian is right around the corner I'm satisfied with a terrible hack: just uniq bindist.list before producing the bindist tarball. Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13979, #13974 Differential Revision: https://phabricator.haskell.org/D3767 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:17:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:17:57 -0000 Subject: [GHC] #13979: Don't use gtar to produce FreeBSD binary distribution In-Reply-To: <046.b22f0776065bd354178bf07bc0410857@haskell.org> References: <046.b22f0776065bd354178bf07bc0410857@haskell.org> Message-ID: <061.238652ba673e7d9fe146d6f454d407eb@haskell.org> #13979: Don't use gtar to produce FreeBSD binary distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Phab:D3767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: The fix in comment:6 is really a workaround, but it's as close as we'll likely get with the Make-based build system. Merged to `ghc-8.2` with 96ce53866496b72a3eb34ee13a2a9c5392c29fcb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:18:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:18:22 -0000 Subject: [GHC] #13984: Panic when using a TH splice in a do bind pattern In-Reply-To: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> References: <047.261df4fdf027976c22dd89bf3806cbeb@haskell.org> Message-ID: <062.e9961f5487dc9afd1ec236e58cb206bf@haskell.org> #13984: Panic when using a TH splice in a do bind pattern -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: fixed | Keywords: panic | template-haskell 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): Phab:D3766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` with b45d1277ada4b5ce30d5cfa188fb020f4806d9ea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:23:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:23:58 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.bec6bd3c7c4b266bd439d55d1807c13b@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: In general it's appreciated if you can provide at very least a title for new tickets. In this particular case I think the error message pretty much explains what's going on here: there are two instances which may match your request. GHC in general refuses to choose arbitrarily. If you want to force GHC to choose arbitrarily then you can use `IncoherentInstances`, but you get to keep both pieces if your program breaks. Closing as invalid but feel free to reopen if I have misunderstood your request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:26:21 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 (was: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8) In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.1eb638571ac3f72dea87b6e452231676@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * milestone: => 8.2.1 * resolution: => fixed Comment: I believe the `tar` issue should now be fixed (see #13979). I think the `libutil` issue should be resolved as well as I'm now doing the builds on FreeBSD 11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:29:27 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.bdb06975a97dc86a620484e95408a97d@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Comment (by bgamari): In general your code will perform pretty poorly with or without worker/wrapper if you have >100 arguments as this is well beyond what we can accommodate in physical registers. Of course, I'm happy to be proven wrong: do you have a concrete example of a program with this many arguments which you think should optimize well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:40:27 -0000 Subject: [GHC] #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals In-Reply-To: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> References: <044.e5fed92056d8e0b7a9995970bba113c1@haskell.org> Message-ID: <059.7f04f8c1b6191f97daf01602545ef456@haskell.org> #13967: Simplifier ticks exhausted (when trying UnfoldingDone) from using lots of ByteString Builder literals -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: I'm pretty confident that this is a duplicate of #13960. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 02:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 02:42:38 -0000 Subject: [GHC] #13960: Ticks exhausted with 8.0.2 In-Reply-To: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> References: <046.fbe964ac84173f815e6644f2d34435fc@haskell.org> Message-ID: <061.42527a31b6316ad3e34ff367d9443e2c@haskell.org> #13960: Ticks exhausted with 8.0.2 -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => upstream Comment: At this point we are waiting on `bytestring` upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 03:43:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 03:43:52 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.04d4ce05984f6154414e7c43105c8a31@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > this ticket has convinced me that it's not special afte all. I wholehartedly agree with removal of this check (The second check was an error originally, we had to downgrade it to warning because of false positives, and now even that is not good enough.) I think it is inevitable that we will have some transformations making choices that – after some other transformations – are no longer verifiable by CoreLint. (Incidentally, this also means that we have transformations in GHC that produce non-well-typed Core, if we consider “well-typed” to mean “we can prove progress and preservation”. This is not a shortcoming of GHC, but rather of the notion of well-typedness, though.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 03:57:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 03:57:09 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter Message-ID: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: | wiki:PrettyErrors -------------------------------------+------------------------------------- GHC has for a long time used the `pretty` library for pretty-printing. However, for a number of reasons (explained in wiki:PrettyErrors) it leaves some things to be desired. The `prettyprinter` library is a performant, well-supported alternative that looks quite promising. Explore moving to `prettyprinter` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 03:59:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 03:59:06 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.8341dbd165418be1fd59c4fa2213cdb3@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3650 Comment: @bollu has offered to look into moving GHC to it and even has a branch (Phab:D3650) starting the process. Unfortunately, he ran into a rather tricky correctness issue: the inplace `ghc-pkg` fails during the build with, {{{ /home/ben/ghc/ghc-testing/inplace/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (not a ghc-pkg db file, wrong file magic number) }}} It seems possible that this this due to faulty code generation due to minor differences in pretty-printer output, but it's really quite unclear. This needs further investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 03:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 03:59:19 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.87027fbfffc8698f5b7adf188aa7d86e@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bollu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 04:24:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 04:24:30 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.24cc48d820b52c92a55696adabf22a88@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): After adding some extra debug output to `GHC.PackageDb.getHeader` I see this, {{{ /home/ben/ghc/ghc-testing/inplace/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (not a ghc-pkg db file, wrong file magic number (saw "\NULghcpkg\NUL\NUL\NUL\NUL\SOH\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\SOH\NUL", expected "\192\231hcpkg\192\128dbModuleUnitId")) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 04:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 04:26:24 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.32ddf232424f912841ee01b9ad0264d9@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 04:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 04:29:54 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.6b4ca136f4261e5bb5b9dfde1a43207b@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Changes (by zaoqi): * status: closed => new * resolution: invalid => Old description: > {{{#!hs > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} > > class GEq a b where > geq :: a -> b -> Bool > > instance {-# OVERLAPPING #-} Eq a => GEq a a where > geq = (==) > > instance GEq a b where > geq _ _ = False > }}} > > {{{ > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> :load GEq.hs > [1 of 1] Compiling Main ( GEq.hs, interpreted ) > Ok, modules loaded: Main. > *Main> geq::a->b->Bool > > :3:1: > Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ > Matching instances: > instance GEq a b -- Defined at GEq.hs:9:10 > instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 > (The choice depends on the instantiation of ‘a1, b1’ > To pick the first instance above, use IncoherentInstances > when compiling the other instance declarations) > In the expression: geq :: a -> b -> Bool > In an equation for ‘it’: it = geq :: a -> b -> Bool > *Main> > }}} New description: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPING #-} Eq a => GEq a a where geq = (==) instance GEq a b where geq _ _ = False }}} {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq::a->b->Bool :3:1: Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ Matching instances: instance GEq a b -- Defined at GEq.hs:9:10 instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 (The choice depends on the instantiation of ‘a1, b1’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the expression: geq :: a -> b -> Bool In an equation for ‘it’: it = geq :: a -> b -> Bool *Main> }}} In order to {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} data Dyn :: * where Dyn :: a -> Dyn instance Eq Dyn where ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 08:32:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 08:32:01 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.f14a3a04e79d1e3980df4ccf8bd99357@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgj): I do not think doing the builds on FreeBSD 11 would be the solution to this problem. The issue with {{{libutil.so}}} is due to the updates done in the FreeBSD base system between major versions 8.x and 10.x. The published binary distribution was built on FreeBSD 8.4 because that was the oldest supported version of FreeBSD at that time. That is a general practice to make it possible for FreeBSD users to use exactly the same binaries on multiple major versions, because there is a backward compatibility maintained between them. In order to use this distribution on a 10.3 system, one has to install the {{{misc/compat8x}}} package that contains the missing version of {{{libutil.so}}} (among many other older versions of libraries). Hence I would recommend to build the recent FreeBSD binary distributions on 10.3 instead as that is the [https://www.freebsd.org/security/security.html#sup oldest supported version at the moment] (until about April 30, 2018). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 08:44:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 08:44:46 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.bffc94d81971aa33949d54cf9c9556ce@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 Resolution: fixed | 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 albertov): Amazing. I'm building a new ghc right now to test it. Sorry I couldn't do it before, I didn't expect it to be fixed so quickly! Thanks bgamari! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 11:01:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 11:01:46 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.14cd25d51124edffce6c9ca1a96ee5dd@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Comment (by choenerzs): I'm using a lot of intermediate data constructors for control flow which are all eliminated if SpecConstr runs to completion. The ```100``` for W/W was only to provide a ceiling I'm not likely to bump against. However, this is part of the problem, in that the user of the library now needs to think about which value to give W/W. The function wstream_Strng2_V_1 becomes more than x10 faster if specconstr runs to completion and allocates *a lot* less (in my allocation benchmark it is 48 bytes versus ~ 600 Kilo-bytes . It has arity 18 after full SpecConstr. In GHC 8.0.2 and earlier, I did not have to change the maximal number of W/W arguments for SpecConstr. The core output for v1-slow (W/W = 10) and v1-fast (W/W = 100) is given as attachments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 11:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 11:03:00 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.3b3df21462868c7054499ff413ba476e@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Changes (by choenerzs): * Attachment "v1-slow.dump-simpl" added. core output with default W/W 10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 11:03:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 11:03:21 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.d836573963f6a99e3289fc9317730394@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Changes (by choenerzs): * Attachment "v1-fast.dump-simpl" added. core output with W/W 100 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 12:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 12:21:54 -0000 Subject: [GHC] #13803: Panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.5fd6949417f66553983c80f17489c157@haskell.org> References: <044.5fd6949417f66553983c80f17489c157@haskell.org> Message-ID: <059.7d55749395c87b6a8fcc82d867ebc39a@haskell.org> #13803: Panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: hs-boot 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): Phab:D3742 Wiki Page: | -------------------------------------+------------------------------------- Comment (by inaki): Thanks for the fix, I just gave it a try. Unfortunately the original issue still seems to be present (perhaps I am hitting #13981?). The error message I am getting is basically the same as before: {{{ : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170720 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing IsFile which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find IsFile in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is when trying to compile `gi-gio`, following the same steps as in the original report, but using GHC 8.2 from git. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 14:37:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 14:37:56 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.cbae9c07b841ff6d7f4e2030e7bb89ef@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): Interesting: so `BS.length headerMagic` apparently evaluates to 23. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 14:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 14:54:28 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.601b555b4f2aeee862d1cff0fd412fb4@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 Resolution: fixed | 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 mnislaih): Hey, thanks a lot to everyone who reported, worked and ultimately fixed this bug. We (Barclays) only got around to test RC3 yesterday and found that it was nigh impossible to build our code base with it in our Windows environment. Today I built GHC from the 8.2 branch with this fix included and it's all good again. Thanks again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 15:23:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 15:23:08 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error Message-ID: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running GHC with heap profiling and then running `hp2ps` on the result gives {{{ hp2ps: ghc-stage2.hp, line 17405, samples out of sequence }}} Reproduction (GHC commit 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98) {{{ cabal unpack skylighting-0.1.1.5 cd skylighting-0.1.1.5 cabal configure --with-ghc=$HOME/src/ghc-clean-july12/inplace/bin/ghc- stage2 \ --enable-profiling -fexecutable cabal build touch src/Skylighting/Syntax/Php.hs /home/dfeuer/src/ghc-clean-july12/inplace/bin/ghc-stage2 --make -i \ -isrc -idist/build -O -prof -fprof-auto-exported -osuf p_o -hisuf \ p_hi -optPdist/build/autogen/cabal_macros.h -hide-all-packages \ -package-db dist/package.conf.inplace -package-id aeson-1.2.1.0 \ -package base-4.10.0.0 -package blaze-html-0.9.0.1 -package \ bytestring-0.10.8.2 -package case-insensitive-1.2.0.10 -package \ containers-0.5.10.2 -package directory-1.3.0.2 -package \ filepath-1.4.1.2 -package hxt-9.3.1.16 -package mtl-2.2.1 -package \ regex-pcre-builtin-0.94.4.8.8.35 -package safe-0.3.15 -package \ text-1.2.2.2 -package utf8-string-1.0.1.1 -XHaskell2010 \ Skylighting.Types Skylighting.Regex \ Skylighting.Tokenizer Skylighting.Syntax.Php -j1 +RTS \ -s -h -N1 hp2ps ghc-stage2.hp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 16:04:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 16:04:02 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.6b0596a3392b535dfd0c4ba6be999d24@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: Your description still isn't very clear. What exactly is the bug here? Moreover, what does `GEq` have anything to do with `Dyn`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 16:33:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 16:33:30 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.e09f1c685a5845fc328ca0f3383ff129@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm confused. * I think `-fmax-worker-args` applies to the demand analyser, not `SpecConstr`. So I'm not sure how it is affecting things. * Are you getting the same code with 8.0.2 and 8.2 after `SpecConstr`? Overall it's going to be hard to help without a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 16:36:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 16:36:42 -0000 Subject: [GHC] #13970: Segmentation fault inside threadPaused In-Reply-To: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> References: <047.88c742b3e3987772d4fe79ec856eb7df@haskell.org> Message-ID: <062.682e12536e776f061b9164cc96ffafb8@haskell.org> #13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.2.1-rc3 Resolution: fixed | 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 bgamari): I'm glad it helped! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 16:40:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 16:40:03 -0000 Subject: [GHC] #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file In-Reply-To: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> References: <049.1bd216b8e6981f889936467ec43436c0@haskell.org> Message-ID: <064.91f23671fc45e8333ee9f05dfcba3fdf@haskell.org> #14002: Defining a function in GHCi results in different strictness behavior than defining it in a file -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): If you use `-fpedantic-bottoms` you get the behaviour you expect. This is all discussed in `CoreArity`, reproduced below. It's not great, but I don't know how to fix it without imposing an unacceptable performance penalty. {{{ Note [Dealing with bottom] ~~~~~~~~~~~~~~~~~~~~~~~~~~ A Big Deal with computing arities is expressions like f = \x -> case x of True -> \s -> e1 False -> \s -> e2 This happens all the time when f :: Bool -> IO () In this case we do eta-expand, in order to get that \s to the top, and give f arity 2. This isn't really right in the presence of seq. Consider (f bot) `seq` 1 This should diverge! But if we eta-expand, it won't. We ignore this "problem" (unless -fpedantic-bottoms is on), because being scrupulous would lose an important transformation for many programs. (See Trac #5587 for an example.) Consider also f = \x -> error "foo" Here, arity 1 is fine. But if it is f = \x -> case x of True -> error "foo" False -> \y -> x+y then we want to get arity 2. Technically, this isn't quite right, because (f True) `seq` 1 should diverge, but it'll converge if we eta-expand f. Nevertheless, we do so; it improves some programs significantly, and increasing convergence isn't a bad thing. Hence the ABot/ATop in ArityType. So these two transformations aren't always the Right Thing, and we have several tickets reporting unexpected behaviour resulting from this transformation. So we try to limit it as much as possible: (1) Do NOT move a lambda outside a known-bottom case expression case undefined of { (a,b) -> \y -> e } This showed up in Trac #5557 (2) Do NOT move a lambda outside a case if all the branches of the case are known to return bottom. case x of { (a,b) -> \y -> error "urk" } This case is less important, but the idea is that if the fn is going to diverge eventually anyway then getting the best arity isn't an issue, so we might as well play safe (3) Do NOT move a lambda outside a case unless (a) The scrutinee is ok-for-speculation, or (b) more liberally: the scrutinee is cheap (e.g. a variable), and -fpedantic-bottoms is not enforced (see Trac #2915 for an example) Of course both (1) and (2) are readily defeated by disguising the bottoms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 17:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 17:05:15 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.6486d9f79d6c962b041b4872d73e8be0@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): One issue is that `prettyprinter` lacks an analogue to `pretty`'s `($$)` operator, which has `empty` as an identity. See https://github.com/quchen/prettyprinter/issues/34. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 17:06:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 17:06:47 -0000 Subject: [GHC] #14007: CI builds for integer-simple variant of GHC for Windows Message-ID: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> #14007: CI builds for integer-simple variant of GHC for Windows ---------------------------------------+--------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- Currently for Haskell production non-open-source software integer-simple builds of GHC for Windows are needed. GMP Integer library is GPL and cannot be used for such production software. Is it possible to make such official builds of GHC? This will stimulate more Haskell as a production language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 17:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 17:58:36 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.68658ad2a4ee68eca964fabbca47bfac@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): The problem appears to be the encoding of the string literal itself in the object code. Previously we would find this, {{{ starts here 0531220 - b o o t - 8 . 3 \0 300 200 g h c p 0531240 k g 300 200 \0 d b M o d u l e U n i ^ ends here }}} Now we find this, {{{ starts here 0534520 o o t - 8 . 3 \0 303 200 200 g h c p k 0534540 g 303 200 200 \0 d b M o d u l e U n i ^ ends here }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 18:01:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 18:01:50 -0000 Subject: [GHC] #14007: CI builds for integer-simple variant of GHC for Windows In-Reply-To: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> References: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> Message-ID: <060.451dd57dcdf1feb86a4cb520990eb1d9@haskell.org> #14007: CI builds for integer-simple variant of GHC for Windows ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by nickkuk): Correction: GMP has LGPL license. You can use it as dynamic library, i.e. as .dll in windows, or as .so in linux (e.g. as a standard package). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 18:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 18:19:33 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.4c0ded138d28aa796776a04cbee3a1fa@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, well the issue was actually fairly obvious: We are now producing `.s` files in UTF-8 instead of ISO 8859-1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 18:34:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 18:34:46 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.69d30f8d80a0578baf7f96f51c559db9@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by borsboom): I've hit the same problem with GHC 8.0.2. Building unicode- transforms-0.3.1 works with GHC 7.10.3 and LLVM 3.5.2, but has the "`opt' failed in phase `LLVM Optimiser'" error with GHC 8.0.2 and LLVM 3.7.1. This is on an emulated armv7 with 1 GB of RAM and 4 GB swap running Debian jessie. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 18:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 18:39:23 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.4156f10014c17a12bf347aa7c57f3814@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds like it ran out of memory. What does `dmesg` say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 19:04:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 19:04:33 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.cb4fef23029fa6ab76d0482105e99191@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion 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: | -------------------------------------+------------------------------------- Comment (by choenerzs): SpecConstr checks via ```isWorkerSmallEnough``` in ```callsToNewPats``` if the pattern to be specialised is small enough. This is controlled by ```-fmax-worker-args```. Line 1913 in SpecConstr.hs. And no, 8.0.2 fully specialises irrespective of the number of worker arguments. Specialisation in 8.2 depends on the number of arguments the pattern to be specialised has. I'll try to construct a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 20:59:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 20:59:28 -0000 Subject: [GHC] #10684: Error cascade when unrelated class derivation fails In-Reply-To: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> References: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> Message-ID: <060.77e8e98d47329984a758ff32219417b6@haskell.org> #10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3771 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3771 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 21:05:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 21:05:57 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.c40039336801a3cef416454227007275@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11565 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11565 Comment: > The function `wstream_Strng2_V_1` becomes more than x10 faster if specconstr runs to completion and allocates *a lot* less (in my allocation benchmark it is 48 bytes versus ~ 600 Kilo-bytes . It has arity 18 after full SpecConstr. Where is this `wstream_Strng2_V_1` function that you refer to? It would be helpful to see a concrete example. > And no, 8.0.2 fully specialises irrespective of the number of worker arguments. Specialisation in 8.2 depends on the number of arguments the pattern to be specialised has. This change is due to two causes: * a48de37dcca98e7d477040b0ed298bcd1b3ab303, which fixes #11565 where `-fmax-worker-args` was simply ignored * f93c363fab1ac8ce6f0b474f5967b0b097995827, which extended the reach of `-fmax-worker-args` to include SpecConstr in order to improve compiler performance. Perhaps you want the SpecConstr limit to be independent from the worker/wrapper limit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 21:21:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 21:21:59 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.ef883d0f36e5fc48d25d7122dd7b74d9@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by borsboom): Nothing of interest in `dmesg`, and I just tried again while logging memory usage, and the system was nowhere near running out of memory (half the RAM was still being used for cache, and no swap usage) just before it terminated: {{{ $ free -m total used free shared buffers cached Mem: 1005 912 93 0 29 575 -/+ buffers/cache: 307 697 Swap: 3813 14 3799 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 21:59:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 21:59:45 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.ad09ec8f0fca79b3188a6c6495760d39@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by inaki): * cc: inaki (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 22:04:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 22:04:53 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.918318e8d88cfd52b48026c9a1d36fb7@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: fixed | Keywords: hs-boot 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 inaki): I think that this issue got perhaps closed by mistake? The commit mentions explicitly that this issue is not fixed yet, and `ghc A.hs` does indeed still give rise to a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 21 23:15:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Jul 2017 23:15:53 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.2333b70cff41fa6d24b0aaa9dbd94c09@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 AntC): The error I see is that the `{-# OVERLAPPING #-}` pragma is on the wrong instance. The `GEq a a` instance should have `{-# OVERLAPPABLE #-}`; the `GEq a b` should have `{-# OVERLAPPING #-}`. The instance for `Dyn` doesn't mention `GEq`. I agree with Ben, Ryan: I see no bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 02:05:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 02:05:11 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.ef542ebe7d5c50888036dd9df1500029@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by bgamari): I have cherry-picked comment:15 into `ghc-8.2` and it will be present in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 02:56:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 02:56:18 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.f661265b7404a31de2b906de4746a4dd@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not really sure what to say about this; given that it's `opt` crashing there is nothing to suggest that this is in fact an GHC bug. Can you reproduce this with GHC 8.2.1-rc3 and LLVM 3.9? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 04:24:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 04:24:02 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.f25bd664eb6bce9a180fe770c191a5d3@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => * milestone: 8.2.1 => 8.4.1 Comment: Indeed it did. Thanks for bringing this to my attention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 05:07:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 05:07:17 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.eed72c24bbcde6540ac701cb7d1f02a2@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Changes (by zaoqi): * status: infoneeded => new Old description: > {{{#!hs > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} > > class GEq a b where > geq :: a -> b -> Bool > > instance {-# OVERLAPPING #-} Eq a => GEq a a where > geq = (==) > > instance GEq a b where > geq _ _ = False > }}} > > {{{ > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> :load GEq.hs > [1 of 1] Compiling Main ( GEq.hs, interpreted ) > Ok, modules loaded: Main. > *Main> geq::a->b->Bool > > :3:1: > Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ > Matching instances: > instance GEq a b -- Defined at GEq.hs:9:10 > instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 > (The choice depends on the instantiation of ‘a1, b1’ > To pick the first instance above, use IncoherentInstances > when compiling the other instance declarations) > In the expression: geq :: a -> b -> Bool > In an equation for ‘it’: it = geq :: a -> b -> Bool > *Main> > }}} > > In order to > {{{#!hs > {-# LANGUAGE KindSignatures, GADTs #-} > data Dyn :: * where > Dyn :: a -> Dyn > > instance Eq Dyn where > ... > }}} New description: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPING #-} Eq a => GEq a a where geq = (==) instance GEq a b where geq _ _ = False }}} {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq::a->b->Bool :3:1: Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ Matching instances: instance GEq a b -- Defined at GEq.hs:9:10 instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 (The choice depends on the instantiation of ‘a1, b1’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the expression: geq :: a -> b -> Bool In an equation for ‘it’: it = geq :: a -> b -> Bool *Main> }}} In order to {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} data Dyn :: * where Dyn :: a -> Dyn instance Eq Dyn where (==) = geq }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 05:08:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 05:08:21 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.03062c7b0d42606766af4873b27bcf43@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Description changed by zaoqi: Old description: > {{{#!hs > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} > > class GEq a b where > geq :: a -> b -> Bool > > instance {-# OVERLAPPING #-} Eq a => GEq a a where > geq = (==) > > instance GEq a b where > geq _ _ = False > }}} > > {{{ > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> :load GEq.hs > [1 of 1] Compiling Main ( GEq.hs, interpreted ) > Ok, modules loaded: Main. > *Main> geq::a->b->Bool > > :3:1: > Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ > Matching instances: > instance GEq a b -- Defined at GEq.hs:9:10 > instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 > (The choice depends on the instantiation of ‘a1, b1’ > To pick the first instance above, use IncoherentInstances > when compiling the other instance declarations) > In the expression: geq :: a -> b -> Bool > In an equation for ‘it’: it = geq :: a -> b -> Bool > *Main> > }}} > > In order to > {{{#!hs > {-# LANGUAGE KindSignatures, GADTs #-} > data Dyn :: * where > Dyn :: a -> Dyn > > instance Eq Dyn where > (==) = geq > }}} New description: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPING #-} Eq a => GEq a a where geq = (==) instance GEq a b where geq _ _ = False }}} {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :load GEq.hs [1 of 1] Compiling Main ( GEq.hs, interpreted ) Ok, modules loaded: Main. *Main> geq::a->b->Bool :3:1: Overlapping instances for GEq a1 b1 arising from a use of ‘geq’ Matching instances: instance GEq a b -- Defined at GEq.hs:9:10 instance [overlapping] Eq a => GEq a a -- Defined at GEq.hs:6:30 (The choice depends on the instantiation of ‘a1, b1’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the expression: geq :: a -> b -> Bool In an equation for ‘it’: it = geq :: a -> b -> Bool *Main> }}} In order to {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} data Dyn :: * where Dyn :: a -> Dyn instance Eq Dyn where Dyn a == Dyn b = geq a b }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 05:11:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 05:11:50 -0000 Subject: [GHC] #14008: NondecreasingIndentation is problematic when the indentation can't be decreased Message-ID: <048.6be048a729a95dbe457fee6f381e6ca7@haskell.org> #14008: NondecreasingIndentation is problematic when the indentation can't be decreased -------------------------------------+------------------------------------- Reporter: allbery_b | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program, which was deliberately mis-indented (someone playing with an exercise with deliberate errors and being confused by the result): {{{#!hs module Print3Broken where printSecond :: IO () printSecond = do putStrLn greeting -- Yarrrrr out of scope main :: IO () main = do putStrLn greeting printSecond where greeting = "Yarrrrr" }}} With `-XNondecreasingIndentation` on by default, this will parse as long as the definition of `main` (or any other definition) is not present after the `do` block. But there is no legal way to have a definition after the `do` because it is not possible to unindent from column 1 --- and the resulting parse error is a bit confusing and gives no hint that `NondecreasingIndentation` applied to the `do` is the cause. I suspect `NondecreasingIndentation` should not be applied when it is impossible to decrease the indentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 09:31:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 09:31:24 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.2581199a63eb2d2e09916fb1cf5a1799@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11565 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by choenerzs): The core output of the ```wstream_Strng2_V_1``` function is in the two attached files. I still need to prepare a test case that doesn't depend on a lot of dependencies. What I want is SpecConstr to continue specialising functions that have a ```SPEC``` argument irrespective of the number of arguments. That is, those where sc_force is set, I think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 09:54:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 09:54:38 -0000 Subject: [GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build Message-ID: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> #14009: ghc-8.2.1_rc3 fails unregisterised build -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed when was building --enable-unregisterised build for x86_64: {{{ /tmp/ghc22931_0/ghc_3.hc:5:9: error: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol StgWord __stginit_ghczmprim_GHCziTypes[]__attribute__((aligned(8)))= { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 5 | StgWord __stginit_ghczmprim_GHCziTypes[]__attribute__((aligned(8)))= { | ^ In file included from /tmp/ghc22931_0/ghc_3.hc:3:0: error: /tmp/ghc22931_0/ghc_3.hc:4:5: error: note: previous declaration of '__stginit_ghczmprim_GHCziTypes' was here EF_(__stginit_ghczmprim_GHCziTypes); ^ }}} The error here is mismatch in symbol type: EF_ ("external function") It should be EC_ ("external closure"). The same build failure does not happen in HEAD because the __stginit_* is not generated there anymore (see a92ff5d66182d992d02dfaad4c446ad074582368) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 09:55:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 09:55:11 -0000 Subject: [GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build In-Reply-To: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> References: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> Message-ID: <060.e80e1872731891c96ae45509021b471c@haskell.org> #14009: ghc-8.2.1_rc3 fails unregisterised build -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "0001-Fix-label-type-for-__stginit_-labels-those- are-.data.patch" added. 0001-Fix-label-type-for-__stginit_-labels-those-are-.data.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 09:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 09:55:57 -0000 Subject: [GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build In-Reply-To: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> References: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> Message-ID: <060.727c5b532cfb826235b8a6c545806bda@haskell.org> #14009: ghc-8.2.1_rc3 fails unregisterised build -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 09:59:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 09:59:57 -0000 Subject: [GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol (was: ghc-8.2.1_rc3 fails unregisterised build) In-Reply-To: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> References: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> Message-ID: <060.6d852d6f5d709a6e90aaf35ac312b869@haskell.org> #14009: ghc-8.2.1_rc3 fails unregisterised build: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 12:13:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 12:13:11 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) Message-ID: <048.aef8128a023635f337951aa397b7be20@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this well-typed code: {{{#!hs {-# LANGUAGE NoImplicitPrelude, TypeInType, TypeFamilies, UndecidableSuperClasses, RankNTypes, TypeOperators, FlexibleContexts, TypeSynonymInstances, FlexibleInstances, UndecidableInstances #-} module Monolith where import Data.Kind (Type) import GHC.Exts (Constraint) type family (~>) :: c -> c -> Type type instance (~>) = (->) type instance (~>) = ArrPair type family Fst (p :: (a, b)) :: a where Fst '(x, _) = x type family Snd (p :: (a, b)) :: b where Snd '(_, y) = y data ArrPair a b = ArrPair (Fst a ~> Fst b) (Snd a ~> Snd b) type family Super c :: Constraint where Super Type = () Super (c, d) = (Category c, Category d) class Super cat => Category cat where id :: forall (a :: cat). a ~> a instance Category Type where id = \x -> x instance (Category c, Category d) => Category (c, d) where id = ArrPair id id class Category (c, d) => Functor (f :: c -> d) where --class (Category c, Category d) => Functor (f :: c -> d) where map :: (a ~> b) -> (f a ~> f b) data OnSnd f a b = OnSnd (f '(a, b)) instance Functor (f :: (c, d) -> Type) => Functor (OnSnd f a) where map f (OnSnd x) = OnSnd (map (ArrPair id f) x) }}} The compiler accepts it. But if I change the definition of 'Functor' for the commented one, I get an error: {{{ super.hs:39:10: error: • Could not deduce (Category d) arising from the superclasses of an instance declaration from the context: Functor f bound by the instance declaration at super.hs:39:10-61 Possible fix: add (Category d) to the context of the instance declaration • In the instance declaration for ‘Functor (OnSnd f a)’ | 39 | instance Functor (f :: (c, d) -> Type) => Functor (OnSnd f a) where | }}} I can reproduce this on 8.0.1, 8.2.0.20170704 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 13:24:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 13:24:41 -0000 Subject: [GHC] #13792: Allow building using distro GCC on Windows In-Reply-To: <044.190a71c9e96d6252e4edbb8309f5384f@haskell.org> References: <044.190a71c9e96d6252e4edbb8309f5384f@haskell.org> Message-ID: <059.2fa14b82fdc2045b202963910ffccfc7@haskell.org> #13792: Allow building using distro GCC on Windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3637 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"cbbf0837d47622f1a3e889a59690d96e7947c6cd/ghc" cbbf083/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cbbf0837d47622f1a3e889a59690d96e7947c6cd" fix dllwrap issue. Summary: Always set dllwrap and windres values. Reviewers: austin, hvr, bgamari, trofi Reviewed By: trofi Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13792 Differential Revision: https://phabricator.haskell.org/D3775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 13:50:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 13:50:18 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.fce91dff087c5376dfa2f1ce342690da@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 AntC): Thanks @zaoqi, you've now provided the full `instance Eq Dyn`. It's defining `(==)` in terms of `geq`. But you haven't changed the overlap pragmas -- see my comment:4. So you get the same compile fail. I think your `instance Eq Dyn` is probably not what you want. `geq` looks at whether the ''types'' are the same, not the values. So you're going to get `Dyn "hello" == Dyn "bye"` coming out `True`. You are still not telling us what you think is wrong/what you expect. So far as I can tell, GHC is behaving correctly. I would not expect this code to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:01:38 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.245e0809c01c9eb7d1286a9103a7a6ff@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari): Moreover, there is no way to satisfy the `Eq a` constraint needed by `geq a b`. Afterall, the `a` type variable here is brought into scope by pattern-matching on the `Dyn` constructor which provides no constraints; not even `Typeable`, so it's not even possible to know at runtime whether the bound `a` and `b` values are of the same type. To be able to make this comparison work you would need something like, {{{#!hs data Dyn :: * where Dyn :: (Eq a, Typeable a) => a -> Dyn instance Eq Dyn where Dyn (a :: a) == Dyn (b :: b) | Just HRefl <- ra `eqTypeRep` rb = a == b | otherwise = False where ra = typeRep :: TypeRep a rb = typeRep :: TypeRep b }}} For instance, {{{ λ> Dyn (1 :: Int) == Dyn (2 :: Int) False λ> Dyn (1 :: Int) == Dyn (1 :: Int) True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:03:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:03:52 -0000 Subject: [GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol In-Reply-To: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> References: <045.2496adf7a5121c55e36032e4ad30d92d@haskell.org> Message-ID: <060.dad6135ec5e42b1da1292e7a6c09c2fa@haskell.org> #14009: ghc-8.2.1_rc3 fails unregisterised build: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.2.1 => 8.2.2 Comment: Unfortunately this just missed the window for 8.2.1. However, I've merged the patch to `ghc-8.2` with 119ca4c97f7e7ab952420645d3f907008b8468ec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:05:35 -0000 Subject: [GHC] #14008: NondecreasingIndentation is problematic when the indentation can't be decreased In-Reply-To: <048.6be048a729a95dbe457fee6f381e6ca7@haskell.org> References: <048.6be048a729a95dbe457fee6f381e6ca7@haskell.org> Message-ID: <063.7c033653237efa5ac72b1507aa6d73f0@haskell.org> #14008: NondecreasingIndentation is problematic when the indentation can't be decreased -------------------------------------+------------------------------------- Reporter: allbery_b | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I suspect `NondecreasingIndentation` should not be applied when it is impossible to decrease the indentation. This sounds reasonable to me. Would you like to offer a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:15:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:15:52 -0000 Subject: [GHC] #14008: NondecreasingIndentation is problematic when the indentation can't be decreased In-Reply-To: <048.6be048a729a95dbe457fee6f381e6ca7@haskell.org> References: <048.6be048a729a95dbe457fee6f381e6ca7@haskell.org> Message-ID: <063.e438c81ee3f9f09550a3e7e3908efc13@haskell.org> #14008: NondecreasingIndentation is problematic when the indentation can't be decreased -------------------------------------+------------------------------------- Reporter: allbery_b | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3777 Comment: Meh, never mind. Here's a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:20:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:20:24 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.23d294e7ee34784ad6c0f082af7abdd9@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 AntC): Hi @bgamari, I got this to work just changing the pragmas, per my comment:7. (So I editted that comment after posting.) Note there's a `Eq a =>` constraint on the `GEq a a` instance; but not on the `GEq a b`. {{{ Dyn "hello" == Dyn "bye" ===> False Dyn "hello" == Dyn "hello" ===> True Dyn "hello" == Dyn 'b' ===> False }}} I agree @zaoqi's definition for `Dyn` is 'dodgy'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 14:47:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 14:47:42 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.6876303368a779e45e8d302be40328cf@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by borsboom): Gave it a try, but unfortunately the LLVM 3.9 bindists at http://releases.llvm.org/download.html#3.9.1 seem to be incompatible with my system and I can't risk breakage by upgrading it right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 15:53:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 15:53:22 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.715ba8cc454a5fd413859349e0668658@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Given the difficulty of fixing compiler bugs of excessive memory use, does it make sense to introduce a test to prevent future regressions: bash -c 'ulimit -v GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 15:57:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 15:57:55 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.15bb5be3b94d4cf3ccbb147f459038f1@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: george (removed) * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 16:05:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 16:05:27 -0000 Subject: [GHC] #14011: T3807 fails to build on FreeBSD Message-ID: <046.e2130ab00a168c1b4e64423cf91f7c05@haskell.org> #14011: T3807 fails to build on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- FreeBSD doesn't have a `libdl`; instead it provides `dlopen` and friends in `libc`. Consequently this testcase fails to link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 16:16:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 16:16:08 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.e59f050099e85186eb9f4ab76748001c@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, we have a testsuite which includes a variety of performance tests. However, they tend to be "microbenchmarks" are don't approach the scale of `vector`. Unfortunately, these tests IMHO already require far more effort to maintain than they give us benefit due to the need for manual bumping of thresholds. The problem is summarized in #12758 (which jared-w is working on fixing this summer). I do think there is room for more compiler performance tests, but I think they should generally be something that we monitor, not something that we actively need to bump thresholds on. As far as using the `vector` testsuite for such a testcase is concerned, I'd skeptical of including it wholesale. Rather, I think we would be better off building a minimized version of `vector`'s testcase (which will hopefully fall out naturally as a result of working on this ticket) and including that. Testcases with lots of dependencies are generally problematic as you get breakage due to interface changes, spurious performance fluctuations due to changes in dependencies, and the pain of having to track down where in your testcase GHC is regressing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 16:40:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 16:40:28 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD Message-ID: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> #14012: External interpreter fails on FreeBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ $ inplace/bin/ghc-stage2 -fexternal-interpreter --interactive GHCi, version 8.3.20170722: http://www.haskell.org/ghc/ :? for help {handle: }: GHCi.Message.remoteCall: end of file }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 16:40:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 16:40:45 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD In-Reply-To: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> References: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> Message-ID: <061.66007c49206708a492e058c8511ff151@haskell.org> #14012: External interpreter fails on FreeBSD ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by bgamari: Old description: > {{{ > $ inplace/bin/ghc-stage2 -fexternal-interpreter --interactive > GHCi, version 8.3.20170722: http://www.haskell.org/ghc/ :? for help > {handle: }: GHCi.Message.remoteCall: end of file > }}} New description: On FreeBSD 11, {{{ $ inplace/bin/ghc-stage2 -fexternal-interpreter --interactive GHCi, version 8.3.20170722: http://www.haskell.org/ghc/ :? for help {handle: }: GHCi.Message.remoteCall: end of file }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 18:48:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 18:48:43 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) In-Reply-To: <048.aef8128a023635f337951aa397b7be20@haskell.org> References: <048.aef8128a023635f337951aa397b7be20@haskell.org> Message-ID: <063.a2f453e019292dfcf445c879a17012d1@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableSuperClasses 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:13:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:13:13 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.156b635ec9aa0e078f010aa76916645b@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record I did the 8.2.1 builds on both 11 and 10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:13:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:13:31 -0000 Subject: [GHC] #14013: Bad monads performance Message-ID: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled, not all extensions are needed): {{{ {-# LANGUAGE AllowAmbiguousTypes, ApplicativeDo, Arrows, BangPatterns, BinaryLiterals, ConstraintKinds, DataKinds, DefaultSignatures, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveTraversable, DoAndIfThenElse, DuplicateRecordFields, EmptyDataDecls, FlexibleContexts, FlexibleInstances, FunctionalDependencies, GeneralizedNewtypeDeriving, InstanceSigs, LambdaCase, MonadComprehensions, MultiWayIf, NamedWildCards, NegativeLiterals, NoImplicitPrelude, NumDecimals, OverloadedLabels, PackageImports, QuasiQuotes, RankNTypes, RecursiveDo, ScopedTypeVariables, StandaloneDeriving, TemplateHaskell, TupleSections, TypeApplications, TypeFamilies, TypeFamilyDependencies, TypeOperators, ViewPatterns, LiberalTypeSynonyms, RelaxedPolyRec #-} module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:15:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:15:40 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.84af9cab89a4103121305c13178576e4@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, my [[https://github.com/bgamari/ghc/commit/5256c89d3172d353d4ebc595b8c38c7ae5a796c9|branch]] contains a rather hacky fix for this in issue (at least in the case of the NCG). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:17:22 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.835dbff1056179003671956cbc1bdf63@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled, not all extensions are needed): > > {{{ > > {-# LANGUAGE AllowAmbiguousTypes, ApplicativeDo, Arrows, BangPatterns, > BinaryLiterals, > ConstraintKinds, DataKinds, DefaultSignatures, DeriveDataTypeable, > DeriveFoldable, > DeriveFunctor, DeriveGeneric, DeriveTraversable, DoAndIfThenElse, > DuplicateRecordFields, > EmptyDataDecls, FlexibleContexts, FlexibleInstances, > FunctionalDependencies, GeneralizedNewtypeDeriving, > InstanceSigs, LambdaCase, MonadComprehensions, MultiWayIf, > NamedWildCards, NegativeLiterals, > NoImplicitPrelude, NumDecimals, OverloadedLabels, PackageImports, > QuasiQuotes, RankNTypes, > RecursiveDo, ScopedTypeVariables, StandaloneDeriving, TemplateHaskell, > TupleSections, > TypeApplications, TypeFamilies, TypeFamilyDependencies, TypeOperators, > ViewPatterns, > LiberalTypeSynonyms, RelaxedPolyRec #-} > > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled, not all extensions are needed): {{{ {-# LANGUAGE AllowAmbiguousTypes, ApplicativeDo, Arrows, BangPatterns, BinaryLiterals, ConstraintKinds, DataKinds, DefaultSignatures, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveTraversable, DoAndIfThenElse, DuplicateRecordFields, EmptyDataDecls, FlexibleContexts, FlexibleInstances, FunctionalDependencies, GeneralizedNewtypeDeriving, InstanceSigs, LambdaCase, MonadComprehensions, MultiWayIf, NamedWildCards, NegativeLiterals, NoImplicitPrelude, NumDecimals, OverloadedLabels, PackageImports, QuasiQuotes, RankNTypes, RecursiveDo, ScopedTypeVariables, StandaloneDeriving, TemplateHaskell, TupleSections, TypeApplications, TypeFamilies, TypeFamilyDependencies, TypeOperators, ViewPatterns, LiberalTypeSynonyms, RelaxedPolyRec #-} module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:20:30 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.16d1169196a002124e9b49459acca04a@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled, not all extensions are needed): > > {{{ > > {-# LANGUAGE AllowAmbiguousTypes, ApplicativeDo, Arrows, BangPatterns, > BinaryLiterals, > ConstraintKinds, DataKinds, DefaultSignatures, DeriveDataTypeable, > DeriveFoldable, > DeriveFunctor, DeriveGeneric, DeriveTraversable, DoAndIfThenElse, > DuplicateRecordFields, > EmptyDataDecls, FlexibleContexts, FlexibleInstances, > FunctionalDependencies, GeneralizedNewtypeDeriving, > InstanceSigs, LambdaCase, MonadComprehensions, MultiWayIf, > NamedWildCards, NegativeLiterals, > NoImplicitPrelude, NumDecimals, OverloadedLabels, PackageImports, > QuasiQuotes, RankNTypes, > RecursiveDo, ScopedTypeVariables, StandaloneDeriving, TemplateHaskell, > TupleSections, > TypeApplications, TypeFamilies, TypeFamilyDependencies, TypeOperators, > ViewPatterns, > LiberalTypeSynonyms, RelaxedPolyRec #-} > > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{ module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:28:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:28:04 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.70e4c5b477f31be755f1ae313ae70a71@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bollu): Would the same fix work for the other backend? Also, why does changing the prettyprinter cause this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 21:51:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 21:51:09 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.5b25dcedccbbb432c44c17db784c56e2@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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 danilo2): @simonpj, there are few things to be explained here: 1. I did not notice that pasting the `(.)` to this file makes it strict (I forgot about the -`Strict` pragma in this file's header). 2. There are some strange things happening with performance when playing with this code, but we've described them separately, here: https://ghc.haskell.org/trac/ghc/ticket/14013 . We can in fact close this topic, because it's main description relates to the fact that the `(.)` operator was pasted into `-XStrict` code and any further discussion here would lead readers to confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:00:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:00:18 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.46d2d6ad5cca50c711d3c916044a83ac@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled): > > {{{ > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{ module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. 7. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:02:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:02:03 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.37d750e3c0635f7a78cdadea957d1a58@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled): > > {{{ > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > 7. The not-yet documented flag `-fspecialise-aggressively` does NOT > affect the results. > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{ module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. 7. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? (GHC even warns: `SPECIALISE pragma for non-overloaded function ‘mtlStateListParser_a_typed’` but it affects performance.) 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:21:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:21:24 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.046a7b40423d08ec7ff225b1a074ac45@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled): > > {{{ > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > 7. The not-yet documented flag `-fspecialise-aggressively` does NOT > affect the results. > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? (GHC even warns: `SPECIALISE pragma for non-overloaded > function ‘mtlStateListParser_a_typed’` but it affects performance.) > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{ module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{ pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{ mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. 7. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463). The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? (GHC even warns: `SPECIALISE pragma for non-overloaded function ‘mtlStateListParser_a_typed’` but it affects performance.) 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:22:19 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.8f1c80f47bd56cc35fc646bfc6e2f2cb@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mqudsi): I just wanted to report back that the 8.2.1 release works swimmingly on my FreeBSD test. I accidentally deployed the 10.3 package on FreeBSD 11 and it worked fine, fwiw. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:23:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:23:55 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.fc696eb692cc8386bf9147d9fe148bc1@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mqudsi): @pgj _if_ misc/compat8x is still a requirement (it does not seem to be necessary w/ the latest), then the configure script should error out w/ a useful message so that it is not a `make install` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 22 22:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Jul 2017 22:25:18 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.74b2c31016ef501ba81eeee4ad2a3672@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @bgmari, I'm sorry, due to completely lack of time while moving to new back-end architecture, we didn't hunted it down and it stopped slowing us down. Let's close this issue, as fast as it appears again, I'll prepare minimal example. I'm really sorry I did not cut it down that time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 00:46:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 00:46:51 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.b3d2f338aa13c08035a77e3e3bf2b5e5@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * status: new => patch * failure: None/Unknown => Documentation bug * differential: => Phab:D3778 Comment: I've submitted a patch implementing option 2. Additionally, a fair bit of work was done to bring all the other pieces into line, so now almost all flag related references should be valid. Those that are not (there are about 350) are references to flags with no documentation. I noticed that most places in the docs that referenced flags with arguments manually appended them to the ref anyway. This way they are now automatically included. I also added a note about how to quickly find the proper flag argument names for easy copy-pasting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 03:49:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 03:49:55 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.ff1b5512c37213beada812d19acd3822@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | Keywords: TypeFamilies Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => invalid Comment: It's quite alright! Thanks for reporting it and let's hope we can nail it in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 03:54:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 03:54:43 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.8acfd4bfb6e6552a29c71733244dc1b4@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled): > > {{{ > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{ > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{ > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > 7. The not-yet documented flag `-fspecialise-aggressively` does NOT > affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463). > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? (GHC even warns: `SPECIALISE pragma for non-overloaded > function ‘mtlStateListParser_a_typed’` but it affects performance.) > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{#!hs module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{#!hs pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{#!hs mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. 7. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463). The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? (GHC even warns: `SPECIALISE pragma for non-overloaded function ‘mtlStateListParser_a_typed’` but it affects performance.) 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- Comment (by bgamari): Very interesting; this will be an interesting thing to mull over tomorrow morning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 03:56:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 03:56:24 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.a02b179d29de48f328211861d6773885@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 05:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 05:37:16 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.cbec2d2a9e99398c860a1f5dfa46590e@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:13 bgamari]: > For the record I did the 8.2.1 builds on both 11 and 10.3. That problem is for the run time, not for the build time. What I was talking about is to build the package on one version of the system, and use it on multiple other versions of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 05:40:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 05:40:11 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.aa8862e4f9899efc3ecb9671833111f0@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:14 mqudsi]: > I just wanted to report back that the 8.2.1 release works swimmingly on my FreeBSD test. > > I accidentally deployed the 10.3 package on FreeBSD 11 and it worked fine, fwiw. That is probably because the base system did not have version changes in the libraries that are required for running the binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 05:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 05:42:25 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.8e07cfbaa04b076fd758157105caa81c@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 zaoqi): Replying to [comment:9 AntC]: > Hi @bgamari, I got this to work just changing the pragmas, per my comment:7. (So I editted that comment after posting.) Note there's a `Eq a =>` constraint on the `GEq a a` instance; but not on the `GEq a b`. > > {{{ > > Dyn "hello" == Dyn "bye" ===> False > Dyn "hello" == Dyn "hello" ===> True > Dyn "hello" == Dyn 'b' ===> False > > }}} > > I agree @zaoqi's definition for `Dyn` is 'dodgy'. {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} data Dyn :: * where Dyn :: a -> Dyn instance Eq Dyn where Dyn a == Dyn b = geq a b class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPABLE #-} (Eq a) => GEq a a where geq = (==) instance {-# OVERLAPPING #-} GEq a b where geq _ _ = False }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Dyn.hs [1 of 1] Compiling Main ( Dyn.hs, interpreted ) Ok, modules loaded: Main. *Main> Dyn () == Dyn () False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 05:54:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 05:54:34 -0000 Subject: [GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 In-Reply-To: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> References: <045.00e3f35e873eeac7dd7d9c3b9d27a9b0@haskell.org> Message-ID: <060.e0aa4ded36cd0ce3dd7956165ff68445@haskell.org> #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutil.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: None | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgj): Replying to [comment:15 mqudsi]: > @pgj _if_ misc/compat8x is still a requirement (it does not seem to be necessary w/ the latest), then the configure script should error out w/ a useful message so that it is not a `make install` error. It is not a requirement any more as the oldest supported version of FreeBSD has become 10.3-RELEASE in the meantime. I am not sure that your idea would be feasible as this "hack" is just for the vanilla binary distribution in order spare a couple of versions of build. (For example, The FreeBSD Project supports FreeBSD 11.0 and FreeBSD 10.3 at the moment, and tangentially FreeBSD-CURRENT aka. 12, so I do not think there should be separate bindists for each major version, especially if there is a backward compatibility.) In result, the regular {{{configure}}} script should not check for the presence of {{{misc/compat8x}}} as that is just a very specific case and it really depends on circumstances like if there were version changes in libraries such as {{{libutil.so}}}. That is why a FreeBSD-specific README file was provided that named {{{misc/compat8x}}} as a prerequisite for the installation. On the other hand, users are always directed towards using FreeBSD packages as that is officially supported version of software there from the side of the Project. When using packages, no things like {{{compat8x}}} are needed at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 06:54:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 06:54:00 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.ff473f298465dcc21c515e5500392697@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Multiple data points suggest that it does not look like a memory issue. However, we could workaround the bug by splitting the long list. So it looks like `opt` cannot handle the code generated by GHC for a list that is too long. If someone knowledgable about the llvm/IR can pinpoint the issue or raise a bug with llvm upstream that will be helpful. This was working with an earlier version of GHC/LLVM so it is possible that this can be fixed easily. If it is non-trivial to fix for llvm/opt we can just close it and just avoid long lists. In that case, maybe GHC can issue a warning about long list so the the programmer can take appropriate action. In this particular case the list holds static data to initialize a bitmap, maybe this is just a rare use case for such a long list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 07:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 07:27:36 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.892e7c4650960b4f6dac6ff2716e690b@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Comment (by takenobu): I also fixed wiki pages as following: * created an anchor tag for old 'ext-f' in ReadingList [1] and linked them there. * updated old links for each pages. [1]: https://ghc.haskell.org/trac/ghc/wiki/ReadingList#TypeEqualities The relationship between old and new links are below. * System F with Type Equality Coercions (Including post-publication Appendix) * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2007/01/tldi22-sulzmann-with-appendix.pdf * OLD: research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/tldi22-sulzmann-with-appendix.pdf * OLD: research.microsoft.com/~simonpj/papers/ext-f/fc-tldi.pdf * OLD: research.microsoft.com/~simonpj/papers/ext-f/ * Equality proofs and deferred type errors (ICFP'12) * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2012/01/icfp12.pdf * OLD: research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/icfp12.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ * Safe Zero-cost Coercions for Haskell (ICFP'14) * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2016/07/coercible.pdf * OLD: research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf * Closed Type Families with Overlapping Equations (POPL'14) * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2016/07/popl137-eisenberg.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/ext-f /axioms-extended.pdf * OLD: research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/popl137-eisenberg.pdf * Injective Type Families for Haskell (Haskell'15) * NEW: www.microsoft.com/en-us/research/wp-content/uploads/2016/07 /injective-type-families-acm.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/ext-f /injective-type-families-acm.pdf * Comprehensive comprehensions * NEW: www.microsoft.com/en-us/research/wp-content/uploads/2007/09 /list-comp.pdf * OLD: research.microsoft.com/~simonpj/papers/list-comp * Understanding functional dependencies via Constraint Handling Rules * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2016/02/jfp06.pdf * OLD: research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/ * OutsideIn(X) Modular type inference with local assumptions * NEW: www.microsoft.com/en-us/research/wp-content/uploads/2016/02 /jfp-outsidein.pdf * OLD: research.microsoft.com/~simonpj/papers/constraints/index.htm * STM * NEW: wiki.haskell.org/Research_papers/Parallelism_and_concurrency#Lock_free_data_structures_and_transactional_memory * OLD: research.microsoft.com/%7Esimonpj/papers/stm/index.htm * Extending the Haskell Foreign Function Interface with Concurrency * NEW: community.haskell.org/~simonmar/papers/conc-ffi.pdf * OLD: research.microsoft.com/%7Esimonpj/Papers/conc-ffi/index.htm * Haskell on a Shared-Memory Multiprocessor * NEW: community.haskell.org/~simonmar/papers/multiproc.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/parallel/ * Towards Haskell in the Cloud * NEW: www.microsoft.com/en-us/research/wp- content/uploads/2016/07/remote.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/parallel/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 07:32:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 07:32:58 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.c118093ee5585c832468a013abc2f1ad@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: merge Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Changes (by takenobu): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 09:07:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 09:07:16 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.f0ceba7feff0715be2fdbf861b723140@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 AntC): Replying to [comment:10 zaoqi]: Good. You've got it to compile. So we can close the ticket. I apologise: my comment:9 is wrong. I must have confused myself playing with it. Ben is right: > ... it's not even possible to know at runtime whether the bound `a` and `b` values are of the same type. In fact variables `a`, `b` bound by GADT `Dyn` are "rigid type variables". GHC always treats them as different types. They're existentially quantified. See [http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html #generalised-algebraic-data-types-gadts The User Guide on GADTs] So `instance Eq Dyn` will always return False. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 10:39:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 10:39:49 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.ca0a8460cde3a0de1de3431d4f2e632c@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 10:39:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 10:39:52 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.1c1e50512869bc1c196352e36d08ad26@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 zaoqi): Replying to [comment:11 AntC]: > Replying to [comment:10 zaoqi]: > > Good. You've got it to compile. So we can close the ticket. > > I apologise: my comment:9 is wrong. I must have confused myself playing with it. Ben is right: > > > ... it's not even possible to know at runtime whether the bound `a` and `b` values are of the same type. > > In fact variables `a`, `b` bound by GADT `Dyn` are "rigid type variables". GHC always treats them as different types. They're existentially quantified. See [http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html #generalised-algebraic-data-types-gadts The User Guide on GADTs] > > So `instance Eq Dyn` will always return False. How to write the correct `instance Eq Dyn`, do not change `data Dyn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 12:02:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 12:02:14 -0000 Subject: [GHC] #14014: trac guest account doesn't work Message-ID: <044.0f3b42dd439ab19b85f8d3e9e3e30206@haskell.org> #14014: trac guest account doesn't work -------------------------------------+------------------------------------- Reporter: mauke | 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: -------------------------------------+------------------------------------- The bug reporting instructions at https://ghc.haskell.org/trac/ghc/wiki/ReportABug say > To submit an anonymous bug: use login "guest", password "guest" Doing so just results in > Error > > Invalid username or password -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 12:06:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 12:06:50 -0000 Subject: [GHC] #14015: DerivingStrategies dead link in documentation Message-ID: <044.58d1cc356335d26f060328f1ce4ab24b@haskell.org> #14015: DerivingStrategies dead link in documentation -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #deriving-strategies says: > You can read the full algorithm at [http://ghc.haskell.org/trac/ghc/wiki/DerivingStrategies Wiki page]. 1. "Wiki page" is an awful link title. 2. The link goes nowhere: The https://ghc.haskell.org/trac/ghc/wiki/DerivingStrategies page doesn't exist -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:23:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:23:20 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.caa4ba830984c829b8f6624f2b4baaec@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 AntC): Replying to [comment:12 zaoqi]: > Replying to [comment:11 AntC]: > > > > So `instance Eq Dyn` will always return False. > > How to write the correct `instance Eq Dyn`, do not change `data Dyn`. The short answer is: `data Dyn` has the wrong definition for looking inside. Ben has given you one possibility in comment:8. A more simple one is: {{{ data Dyn a where Dyn :: Eq a => a -> Dyn a }}} If you can't change the definition of `Dyn` (why not?), you need to explain what you are trying to achieve. I suggest you ask a question on the cafe (or StackOverflow). GHC is behaving as intended. There's no fault, so Trac is not the place to look for that kind of help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:29:02 -0000 Subject: [GHC] #14016: broken link to associated type family instances? Message-ID: <044.8ebc2fb4d82be36ff113ebc04c7c4803@haskell.org> #14016: broken link to associated type family instances? -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes.html#compiler contains this: > See the section on `associated type family instances ` for more information. This looks like it was meant to be a link but got mangled somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:31:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:31:18 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache Message-ID: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.2.1-rc3 Keywords: | Operating System: Linux Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`. If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.) {{{ $ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache -rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache }}} It results in this message when trying to use ghc or ghci: {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied) }}} (n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:32:38 -0000 Subject: [GHC] #14018: Expose more pipeline functionality to GHC API Message-ID: <046.d609cac0996bcde01452ff40a359a835@haskell.org> #14018: Expose more pipeline functionality to GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- There's many useful functionality in non-exposed modules. For example, `ghc/Main.hs` contains `doMake` [0], which is a one-shop stop for compiling all (non-Haskell + Haskell) source files. Now a GHC API client has to replicate much of this logic to get GHC-alike behavior. Similarly for `parseModeFlags`. Or is the intent here to encourage using of Frontend plugins instead of relying on these internals? [0]: http://stuff.codereview.me/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature&line=696 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:37:24 -0000 Subject: [GHC] #14019: broken link to GHC.Compact Message-ID: <044.673da3e432e242e78a1015bef6909fba@haskell.org> #14019: broken link to GHC.Compact -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes.html #runtime-system contains a broken link: > For more details see the [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- compact- at LIBRARY_compact_VERSION@/GHC-Compact.html GHC.Compact] module. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- compact- at LIBRARY_compact_VERSION@/GHC-Compact.html is 404. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:41:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:41:22 -0000 Subject: [GHC] #14020: grammar in RTS release notes Message-ID: <044.4e5ffc87545e7e79e3c0c83385244c08@haskell.org> #14020: grammar in RTS release notes -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes.html #runtime-system says: > Output of ''[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html #rts-eventlog Event log data]'' can now be configured. Enabling external tools to collect and analyze the event log data while the application is still running. I'm pretty sure that's supposed to be one sentence (with a comma in the middle): Output of ''[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html #rts-eventlog Event log data]'' can now be configured, enabling external tools to collect and analyze the event log data while the application is still running. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:44:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:44:25 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.1a9406675154ff03aff00f3cc4c6a615@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: Thank you takenobu! Having these links in order makes everyones' lifes much easier. I have merged this to `ghc-8.2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 13:51:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 13:51:07 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.671345013cc9fbbfb8f9cf4666cb7387@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * version: 8.2.1-rc3 => 8.2.1 * component: None => Build System * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 14:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 14:46:59 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.2a9cf67f09a8fe65a7da5cfa3c8e9a39@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Without reading all the commentary above: I conjecture that the only way to get this right is to come up with some datatype which serves as evidence that an empty case is acceptable. There may be several constructors of the datatype depending on why GHC believes the empty case, and we may need to do transformations to elements of this type during simplification, etc. In other words, it's all quite like what `Coercion` does for type equality. Then, Lint could check various invariants of the datatype. (Also known as typing rules.) Is this worth it? It certainly doesn't seem like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 14:57:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 14:57:37 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL Message-ID: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.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 principle the GHC 8.2.1 bindist for Debian 8 should work fine on WSL. However, in practice it fails during `make install` with this error, {{{ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 14:58:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 14:58:39 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.db272dce5a6f76d1910c6b21dbad6ee4@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > In principle the GHC 8.2.1 bindist for Debian 8 should work fine on WSL. > However, in practice it fails during `make install` with this error, > {{{ > }}} New description: In principle the GHC 8.2.1 bindist for Debian 8 should work fine on WSL. However, in practice it fails during `make install` with this error, {{{ "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /integer-gmp dist-install "strip" '' '/home/ben/roots/ghc/8.2.1' '/home/ben/roots/ghc/8.2.1/lib/ghc-8.2.1' '/home/ben/roots/ghc/8.2.1/share/doc/ghc-8.2.1/html/libraries' 'v p dyn' ./integer-gmp.cabal has been changed. Re-configuring with most recently used options. If this fails, please run configure manually. Configuring integer-gmp-1.0.1.0... ghc-cabal: Cannot find the program 'ghc'. User-specified path '/home/ben/bin-dist-8.2.1-Linux/ghc/inplace/bin/ghc-stage1' does not refer to an executable and the program is not on the system path. ghc.mk:986: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 1 Makefile:51: recipe for target 'install' failed make: *** [install] Error 2 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 15:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 15:00:07 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.88e76bdfdf716507deb3f5d0907956fc@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ezyang, hvr (added) Comment: It seems that the problem is that `Cabal` saves the path of the in-place `ghc-stage1` from the build environment in `libraries/integer-gmp/dist- install/setup-config`. It's not clear why this only affects WSL. CCing the usual Cabal-ers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 15:31:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 15:31:43 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm Message-ID: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Both `base` and `ghc-prim` have references to symbols provided by `libm`. This dependency should be manifest in their respective cabal files. It seems that some `ld.gold` versions are strict about this. See https://github.com/NixOS/nixpkgs/pull/27584. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 15:32:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 15:32:10 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm In-Reply-To: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> References: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> Message-ID: <061.e430968e42882359935185a2fcb4446a@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3780 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3780 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 16:37:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 16:37:55 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.ff8ad9a2c6bbd75f43a40a1e6903ccb6@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks a lot for doing this, patrickdoc! If you are familiar with Sphinx, it would also be great to knock off #11654 so we can drop `mkUserGuidePart`. In principle I would even be okay with dropping the options summary table if that makes things easier (which would also issues like #12155 out of existance). However, the problem is we still need the flag descriptions for the manpage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 16:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 16:41:27 -0000 Subject: [GHC] #12155: Description of flags cut off In-Reply-To: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> References: <045.2ffe1ef8d3efab06fe4ba333c1ac3add@haskell.org> Message-ID: <060.0ebbca0cf8b0b8e0909b2c3d7aa3d817@haskell.org> #12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: flags Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While Sphinx indeed has its issues, I'm afraid it's the best option I was able to find. While Pandoc is great for document conversion and simple typesetting, it's not so great for full documentation generation. I've been unable to find anything that handles things like indexing, table of contents generation, and cross-referencing better than Sphinx. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 16:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 16:47:17 -0000 Subject: [GHC] #14023: Split up glasgow_exts.rst Message-ID: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> #14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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: -------------------------------------+------------------------------------- The `docs/users-guide/glasgow_exts.rst` is crazy large. This makes it difficult to navigate both while editing and reading. It should probably be split up into multiple files along the top-level headings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 16:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 16:47:33 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.46addfd957f9849f5173afc5675a888a@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Also, #14023 would be another nice thing to polish off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 17:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 17:17:54 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.0c5db3ec21e4d8905aef6705f1eafa03@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 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 YitzGale): For comparison, the same bindist tarball (x86_64 deb8) for 8.0.2 installs just fine on WSL. Are you *sure* this works on other Ubuntu platforms on a virgin machine with no previous GHC install? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 17:57:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 17:57:58 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.91dd64733e37a3e46de43b41603db357@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by patrickdoc): I am not familiar with Sphinx outside of this brief expedition, but I would certainly be willing to take on those tickets. I'm making a full pass of the users guide in general, so I can work those in too. This just happened to be a relatively self-contained chunk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 18:06:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 18:06:37 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.60e2fe7ffb2df4a335c992c80b4c69f1@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13194 | Differential Rev(s): Phab:D3259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 18:08:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 18:08:00 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.5bdacaad92f76c2152b6cbe34637156b@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13354, #13375, | Differential Rev(s): Phab:D3090 #14017 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13354, #13375, #14017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 18:08:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 18:08:38 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.e92bbe20103c14e0988e82ad2354933c@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #13194 | Differential Rev(s): Phab:D3569 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 18:11:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 18:11:17 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.4f17c2cbd0d9568d381a54c63c87545d@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: arybczak (added) * related: => #13375, #13354, #13194 Comment: I believe this more fallout from the atomic package database modification patch. The problem appears to be that `writeFileAtomic` (which is used by `writePackageDb` to populate the package database cache) uses the create- and-rename trick for atomic writes on POSIX platforms. However, when it creates the new file it doesn't take care to set the mode bits. It's not clear to me what should be done about this; what is the "correct" mode for this file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:44:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:44:48 -0000 Subject: [GHC] #14018: Expose more pipeline functionality to GHC API In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.376e5347861bb3a0830ab993e499d2ef@haskell.org> #14018: Expose more pipeline functionality to GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 literon): Generally a lot of magic happening in directly in `main` and `main'`. I found #11194 which implies the Frontend Plugin mode is supposed to shortcut having to reimplement these. That said, the (agreeably short, relative to 'main') functionality of `doMake`, namely compiling the non-Haskell sources is not executed in frontend mode. I wonder if there is a resource (or if there should be) that describes caveats/differences of frontend mode vs other major modes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:47:36 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.069f2adb25d1822abefd859dde1077f7@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"44b090be9a6d0165e2281542a7c713da1799e885/ghc" 44b090b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44b090be9a6d0165e2281542a7c713da1799e885" users-guide: Standardize and repair all flag references This patch does three things: 1.) It simplifies the flag parsing code in `conf.py` to properly display flag definitions created by `.. (ghc|rts)-flag::`. Additionally, all flag references must include the associated arguments. Documentation has been added to `editing-guide.rst` to explain this. 2.) It normalizes all flag definitions to a similar format. Notably, all instances of `<>` have been replaced with `⟨⟩`. All references across the users guide have been updated to match. 3.) It fixes a couple issues with the flag reference table's generation code, which did not handle comma separated flags in the same cell and did not properly reference flags with arguments. Test Plan: `SPHINXOPTS = -n` to activate "nitpicky" mode, which reports all broken references. All remaining errors are references to flags without any documentation. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13980 Differential Revision: https://phabricator.haskell.org/D3778 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:47:36 -0000 Subject: [GHC] #14016: broken link to associated type family instances? In-Reply-To: <044.8ebc2fb4d82be36ff113ebc04c7c4803@haskell.org> References: <044.8ebc2fb4d82be36ff113ebc04c7c4803@haskell.org> Message-ID: <059.cc13b59c9a73ed3d58504e0e57cb09eb@haskell.org> #14016: broken link to associated type family instances? -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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 Ben Gamari ): In [changeset:"2dff2c7fbb5aa68445e617d691451c0427fad0a5/ghc" 2dff2c7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2dff2c7fbb5aa68445e617d691451c0427fad0a5" Fix more documentation wibbles Fixes #14020, #14016, #14015, #14019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:47:36 -0000 Subject: [GHC] #14019: broken link to GHC.Compact In-Reply-To: <044.673da3e432e242e78a1015bef6909fba@haskell.org> References: <044.673da3e432e242e78a1015bef6909fba@haskell.org> Message-ID: <059.92ae6ff888a2fb0bc24a48cdb7e37448@haskell.org> #14019: broken link to GHC.Compact -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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 Ben Gamari ): In [changeset:"2dff2c7fbb5aa68445e617d691451c0427fad0a5/ghc" 2dff2c7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2dff2c7fbb5aa68445e617d691451c0427fad0a5" Fix more documentation wibbles Fixes #14020, #14016, #14015, #14019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:47:36 -0000 Subject: [GHC] #14020: grammar in RTS release notes In-Reply-To: <044.4e5ffc87545e7e79e3c0c83385244c08@haskell.org> References: <044.4e5ffc87545e7e79e3c0c83385244c08@haskell.org> Message-ID: <059.233e7ac46fb0d078ddd06032a7d5f7cf@haskell.org> #14020: grammar in RTS release notes -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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 Ben Gamari ): In [changeset:"2dff2c7fbb5aa68445e617d691451c0427fad0a5/ghc" 2dff2c7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2dff2c7fbb5aa68445e617d691451c0427fad0a5" Fix more documentation wibbles Fixes #14020, #14016, #14015, #14019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:47:36 -0000 Subject: [GHC] #14015: DerivingStrategies dead link in documentation In-Reply-To: <044.58d1cc356335d26f060328f1ce4ab24b@haskell.org> References: <044.58d1cc356335d26f060328f1ce4ab24b@haskell.org> Message-ID: <059.e1444be63ff6baad1c53960aa447c14c@haskell.org> #14015: DerivingStrategies dead link in documentation -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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 Ben Gamari ): In [changeset:"2dff2c7fbb5aa68445e617d691451c0427fad0a5/ghc" 2dff2c7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2dff2c7fbb5aa68445e617d691451c0427fad0a5" Fix more documentation wibbles Fixes #14020, #14016, #14015, #14019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:52:42 -0000 Subject: [GHC] #14018: Describe Frontend Plugin vs othe major mode differences in manual. (was: Expose more pipeline functionality to GHC API) In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.0ceaf9214025c517c9d2213ba7b56600@haskell.org> #14018: Describe Frontend Plugin vs othe major mode differences in manual. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 19:56:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 19:56:10 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.6fb30df9f061e9e344bfba7a2d70a1ec@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3782 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3782 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 20:36:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 20:36:37 -0000 Subject: [GHC] #13980: Broken ghc-flag links in the users guide In-Reply-To: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> References: <049.ded548eb5451c78a0e7dcabd196dbe28@haskell.org> Message-ID: <064.abb2bd89dcc9b3d4784f46cfcc759974@haskell.org> #13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): You will likely want to rebase on top of `master` as I did a pass over the users guide as well (see .2dff2c7fbb5aa68445e617d691451c0427fad0a5). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 20:40:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 20:40:29 -0000 Subject: [GHC] #14020: grammar in RTS release notes In-Reply-To: <044.4e5ffc87545e7e79e3c0c83385244c08@haskell.org> References: <044.4e5ffc87545e7e79e3c0c83385244c08@haskell.org> Message-ID: <059.e54269b46c3cfb645b34779f0bc9378f@haskell.org> #14020: grammar in RTS release notes -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Fixed and merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 20:40:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 20:40:44 -0000 Subject: [GHC] #14016: broken link to associated type family instances? In-Reply-To: <044.8ebc2fb4d82be36ff113ebc04c7c4803@haskell.org> References: <044.8ebc2fb4d82be36ff113ebc04c7c4803@haskell.org> Message-ID: <059.ffe81c2b479ae773abc48f49a1060c37@haskell.org> #14016: broken link to associated type family instances? -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Fixed and merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 20:40:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 20:40:59 -0000 Subject: [GHC] #14015: DerivingStrategies dead link in documentation In-Reply-To: <044.58d1cc356335d26f060328f1ce4ab24b@haskell.org> References: <044.58d1cc356335d26f060328f1ce4ab24b@haskell.org> Message-ID: <059.c32ad376792677458b39b621baa6eeb8@haskell.org> #14015: DerivingStrategies dead link in documentation -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Fixed and merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 20:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 20:41:17 -0000 Subject: [GHC] #14019: broken link to GHC.Compact In-Reply-To: <044.673da3e432e242e78a1015bef6909fba@haskell.org> References: <044.673da3e432e242e78a1015bef6909fba@haskell.org> Message-ID: <059.5d4614cf07deaf2caa2d8a13fd0d0557@haskell.org> #14019: broken link to GHC.Compact -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Fixed and merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 21:23:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 21:23:43 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour Message-ID: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 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 tests T13594 T13822 tc269 are failing for me with BuildFlavour=devel2. They pass with BuildFlavour=validate. I have had a brief look to see if I could fix, but this is beyond my current capabilities. There is a comment in tc269.hs saying that it doesn't typecheck, however that looks to be out of date? test output pasted below: {{{ =====> tc269(normal) 1 of 3 [0, 0, 0] cd "./typecheck/should_compile/tc269.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c tc269.hs -dcore-lint -dcmm-lint -no- user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {k_aSm} tenv [aRJ :-> k_aSm[sk:2]] tenvFVs [aSg :-> k_aSg[tau:1], aSm :-> k_aSm[sk:2]] cenv [] cenvFVs [] tys [k_aRJ[sk:1] -> *] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in ghc:TcCanonical Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2089:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:29 in ghc:TyCoRep substTy, called at compiler/typecheck/TcCanonical.hs:673:36 in ghc:TcCanonical Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for tc269(normal) =====> T13594(normal) 2 of 3 [0, 1, 0] cd "./typecheck/should_compile/T13594.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c T13594.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! {$trModule = Module (TrNameS "main"#) (TrNameS "Bug"#), !x_a1o5 = (1, 2)} [x] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in ghc:DsBinds Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/deSugar/DsBinds.hs:89:71 in ghc:DsBinds Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T13594(normal) =====> T13822(normal) 3 of 3 [0, 2, 0] cd "./typecheck/should_compile/T13822.run" && "/home/doug/ghc- dev/devel2/inplace/bin/ghc-stage2" -c T13822.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -fno-warn-incomplete-patterns Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170723 for x86_64-unknown-linux): ASSERT failed! Bad coercion hole {a1bG}: (I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0]) (I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0]) nominal <(I (x_a19g |> Sym (Ty (Sym cobox))_N) |> D:R:IK[0])>_N I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) I (x_a19g[ssk:3] |> Sym (Ty (Sym cobox))_N) nominal Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 in ghc:TcMType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:304:105 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T13822(normal) Unexpected results from: TEST="T13594 T13822 tc269" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 21:49:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 21:49:58 -0000 Subject: [GHC] #14025: Object file is put in wrong directory when any source has absolute path Message-ID: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> #14025: Object file is put in wrong directory when any source has absolute path -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Files: `/tmp/e/A.hs`, `/tmp/e/dep.c`. Current dir: `/tmp/e`. `ghc -odir /tmp/xyzzy A.hs dep.c`: works as expected, puts `dep.o` in `/tmp/xyzzy`. But try to prefix either `A.hs` or `dep.c` (or both) with `/tmp/e/`, and suddenly `dep.o` is put in `/tmp/e`, not in `/tmp/xyzzy`. Couldn't check with 8.2.1 yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 22:53:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 22:53:35 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.68031729209243c4aac2b67a96a283ba@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case 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: | -------------------------------------+------------------------------------- Comment (by nomeata): A `Coercion` exhibits a property of a type (equal to another type). What you want is a witness of a property of a *value* – quite similar to the “value coercions” that we phantasized a few months ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 23:38:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 23:38:30 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.e7ce217a747ce694ab5cdb9bc3e4d7b2@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! We've been struggling with a very strange GHC behavior on IRC today. > Let's consider the following code (needs mtl and criterion to be > compiled): > > {{{#!hs > module Main where > > import Prelude > import Criterion.Main > import qualified Control.Monad.State.Strict as Strict > import qualified Control.Monad.State.Class as State > import Control.DeepSeq (NFData, rnf, force) > import GHC.IO (evaluate) > import Data.Monoid > > ----------------------------- > -- === Criterion utils === -- > ----------------------------- > > eval :: NFData a => a -> IO a > eval = evaluate . force ; {-# INLINE eval #-} > > liftExp :: (Int -> a) -> (Int -> a) > liftExp f = f . (10^) ; {-# INLINE liftExp #-} > > expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) > expCodeGen f i = do > putStrLn $ "generating input code (10e" <> show i <> " chars)" > out <- eval $ liftExp f i > putStrLn "code generated sucessfully" > return out > {-# INLINE expCodeGen #-} > > expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int > -> Benchmark > expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . > nf p ; {-# INLINE expCodeGenBench #-} > > ------------------------------- > -- === (a*) list parsing === -- > ------------------------------- > > genList_a :: Int -> [Char] > genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > > mtlStateListParser_a_typed :: Strict.State [Char] Bool > mtlStateListParser_a_typed = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a_typed > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_typed #-} > > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > > {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} > {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} > > main = do > defaultMain > [ bgroup "a*" $ > [ bgroup "pure" $ expCodeGenBench > genList_a pureListParser_a <$> [6..6] > , bgroup "mtl.State.Strict" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] > , bgroup "mtl.State.Strict typed" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] > , bgroup "mtl.State.Strict let" $ expCodeGenBench > genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] > ] > ] > > }}} > > The code was compiled with following options (and many other variations): > `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal` > > Everything in this code has `INLINE` pragma. The important part we should > focus on are these two functions: > > {{{#!hs > > pureListParser_a :: [Char] -> Bool > pureListParser_a = \case > 'a':s -> pureListParser_a s > [] -> True > _ -> False > {-# INLINE pureListParser_a #-} > > mtlStateListParser_a :: State.MonadState [Char] m => m Bool > mtlStateListParser_a = State.get >>= \case > 'a':s -> State.put s >> mtlStateListParser_a > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a #-} > }}} > > Which are just "parsers" accepting strings containing only 'a' > characters. The former is pure one, while the later uses `State` to keep > the remaining input. The following list contains performance related > observations: > > 0. For the rest of the points, let's call the performance of > `pureListParser_a` a "good" one and everything worse a "bad" one. > > 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times > slower than `pureListParser_a`. Inspecting CORE we can observe that GHC > jumps between `(# a,b #)` and `(a,b)` representations all the time. > > 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: > Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` > is good (exactly the same as `pureListParser_a`). > > 3. If we do NOT use specialize pragma, but we use explicite, non- > polymorphic type signature `mtlStateListParser_a_typed :: Strict.State > [Char] Bool`, the performance is bad (!), identical to the polymorphic > version without specialization. > > 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic > type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] > Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State > [Char] Bool #-}` we get the good performance. > > 5. If we transform `pureListParser_a` to > > {{{#!hs > mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool > mtlStateListParser_a_let = go where > go = Strict.get >>= \case > 'a':s -> Strict.put s >> go > [] -> return True > _ -> return False > {-# INLINE mtlStateListParser_a_let #-} > }}} > > we again get the good performance without the need to use `SPECIALIZE` > pragmas. > > 6. The performance of all the functions that are not optimized as good as > `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. > > 7. The not-yet documented flag `-fspecialise-aggressively` does NOT > affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463). > > The above points raise the following questions: > > 1. Why GHC does not optimize `mtlStateListParser_a` the same way as > `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` > comes from? > > 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` > pragmas, especially in performance critical code? > > 3. Why providing very-explicite type signature > `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve > the problem unless we use `SPECIALIZE` pragma that tells the same as the > signature? (GHC even warns: `SPECIALISE pragma for non-overloaded > function ‘mtlStateListParser_a_typed’` but it affects performance.) > > 4. Why the trick to alias the body of recursive function to a local > variable `go` affects the performance in any way, especially when it does > NOT bring any variable to the local let scope? > > We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several > people reported exactly the same observations. New description: Hi! We've been struggling with a very strange GHC behavior on IRC today. Let's consider the following code (needs mtl and criterion to be compiled): {{{#!hs module Main where import Prelude import Criterion.Main import qualified Control.Monad.State.Strict as Strict import qualified Control.Monad.State.Class as State import Control.DeepSeq (NFData, rnf, force) import GHC.IO (evaluate) import Data.Monoid ----------------------------- -- === Criterion utils === -- ----------------------------- eval :: NFData a => a -> IO a eval = evaluate . force ; {-# INLINE eval #-} liftExp :: (Int -> a) -> (Int -> a) liftExp f = f . (10^) ; {-# INLINE liftExp #-} expCodeGen :: NFData a => (Int -> a) -> (Int -> IO a) expCodeGen f i = do putStrLn $ "generating input code (10e" <> show i <> " chars)" out <- eval $ liftExp f i putStrLn "code generated sucessfully" return out {-# INLINE expCodeGen #-} expCodeGenBench :: (NFData a, NFData b) => (Int -> a) -> (a -> b) -> Int -> Benchmark expCodeGenBench f p i = env (expCodeGen f i) $ bench ("10e" <> show i) . nf p ; {-# INLINE expCodeGenBench #-} ------------------------------- -- === (a*) list parsing === -- ------------------------------- genList_a :: Int -> [Char] genList_a i = replicate i 'a' ; {-# INLINE genList_a #-} pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} mtlStateListParser_a_typed :: Strict.State [Char] Bool mtlStateListParser_a_typed = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a_typed [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_typed #-} mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} {-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-} {-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-} main = do defaultMain [ bgroup "a*" $ [ bgroup "pure" $ expCodeGenBench genList_a pureListParser_a <$> [6..6] , bgroup "mtl.State.Strict" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a) <$> [6..6] , bgroup "mtl.State.Strict typed" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_typed) <$> [6..6] , bgroup "mtl.State.Strict let" $ expCodeGenBench genList_a (Strict.evalState mtlStateListParser_a_let) <$> [6..6] ] ] }}} The code was compiled with following options (and many other variations): `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal` Everything in this code has `INLINE` pragma. The important part we should focus on are these two functions: {{{#!hs pureListParser_a :: [Char] -> Bool pureListParser_a = \case 'a':s -> pureListParser_a s [] -> True _ -> False {-# INLINE pureListParser_a #-} mtlStateListParser_a :: State.MonadState [Char] m => m Bool mtlStateListParser_a = State.get >>= \case 'a':s -> State.put s >> mtlStateListParser_a [] -> return True _ -> return False {-# INLINE mtlStateListParser_a #-} }}} Which are just "parsers" accepting strings containing only 'a' characters. The former is pure one, while the later uses `State` to keep the remaining input. The following list contains performance related observations: 0. For the rest of the points, let's call the performance of `pureListParser_a` a "good" one and everything worse a "bad" one. 1. The performance of `mtlStateListParser_a` is bad, it runs 10 times slower than `pureListParser_a`. Inspecting CORE we can observe that GHC jumps between `(# a,b #)` and `(a,b)` representations all the time. 2. If we add a specialize pragma `{-# SPECIALIZE mtlStateListParser_a :: Strict.State [Char] Bool #-}`, the performance of `mtlStateListParser_a` is good (exactly the same as `pureListParser_a`). 3. If we do NOT use specialize pragma, but we use explicite, non- polymorphic type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool`, the performance is bad (!), identical to the polymorphic version without specialization. 4. If we use SPECIALIZE pragma together with explicite, non-polymorphic type, so we use BOTH `mtlStateListParser_a_typed :: Strict.State [Char] Bool` AND `{-# SPECIALIZE mtlStateListParser_a_typed :: Strict.State [Char] Bool #-}` we get the good performance. 5. If we transform `pureListParser_a` to {{{#!hs mtlStateListParser_a_let :: Strict.MonadState [Char] m => m Bool mtlStateListParser_a_let = go where go = Strict.get >>= \case 'a':s -> Strict.put s >> go [] -> return True _ -> return False {-# INLINE mtlStateListParser_a_let #-} }}} we again get the good performance without the need to use `SPECIALIZE` pragmas. 6. The performance of all the functions that are not optimized as good as `pureListParser_a` is a lot worse in GHC 8.2.1-rc3 than in 8.0.2. 7. The not-yet documented flag `-fspecialise-aggressively` does NOT affect the results (https://ghc.haskell.org/trac/ghc/ticket/12463). 8. If you do NOT use `INLINE` pragma on functions `mtlStateListParser_a` and `mtlStateListParser_a_typed` their performance is good (so `INLINE` pragma makes it bad until we provide explicit specialization). Moreover, if we use `INLINABLE` pragma instead of `INLINE` on these functions (which logically makes more sense, because they are recursive), performance of the polymorphic one `mtlStateListParser_a` is good, while performance of the explicitly typed `mtlStateListParser_a_typed` is bad until we provide explicite specialization. The above points raise the following questions: 1. Why GHC does not optimize `mtlStateListParser_a` the same way as `pureListParser_a` and where the jumping between `(# a,b #)` and `(a,b)` comes from? 2. Is there any way to tell GHC to automatically insert `SPECIALIZE` pragmas, especially in performance critical code? 3. Why providing very-explicite type signature `mtlStateListParser_a_typed :: Strict.State [Char] Bool` does not solve the problem unless we use `SPECIALIZE` pragma that tells the same as the signature? (GHC even warns: `SPECIALISE pragma for non-overloaded function ‘mtlStateListParser_a_typed’` but it affects performance.) 4. Why the trick to alias the body of recursive function to a local variable `go` affects the performance in any way, especially when it does NOT bring any variable to the local let scope? We've been testing this behavior in GHC 8.0.2 and 8.2.1-rc3 and several people reported exactly the same observations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 23 23:38:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Jul 2017 23:38:49 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.82bc91235f5d8361e427c828093544b8@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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 danilo2): I added new observation - point 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 05:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 05:20:11 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.e28c4e0ce30bc2c019fcb7ade17e3ab0@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * owner: simonmar => (none) * status: closed => new * resolution: wontfix => Comment: I'm researching on combining libuv with ghc's light weight thread recently, here's my initial design: https://github.com/winterland1989/stdio/issues/6. I'll report in this thread if i manage to have some benchmark numbers. If it works, The benifit is quite obvious: we don't have to deal with all the windows/encoding hacks and quirks anymore in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 07:09:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 07:09:01 -0000 Subject: [GHC] #14026: hs_init is not idempotent Message-ID: <048.d7c34f7c6c3aecc7ead1ca4a860e6d63@haskell.org> #14026: hs_init is not idempotent -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- hs_init tries to be idempotent by ignoring all calls but the first one. However, subsequent calls to hs_init do not set argc and argv correctly. Here's a test case: {{{ #include "HsFFI.h" #include "stdio.h" void try_init() { char *argv[] = { "./test", "+RTS", "-s", "-RTS", "arg", 0 }; char **argv_ptr = argv; int argc = sizeof(argv)/sizeof(argv[0]) - 1; hs_init(&argc, &argv_ptr); printf("%d\n", argc); } int main() { try_init(); try_init(); } }}} Result: {{{ 2 5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 08:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 08:44:02 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.41f944211fec9339e5f9e923a98fa083@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): We don't have to deal with the hacks either if we have a clean design in Base that properly uses UTF16 internally as it should for Windows. My feeling on this, is that in order to get things like IOCP working correctly using libuv you still need to change a significant part of base. You still need to - define an new IODevice etc. - change the internal encoding of GHC to support both UTF16 and UTF32 (there is some code for this from when simonmar rewrote the I/O manager but I'm not sure the state it's in). - somehow get the scheduler of libuv to interact nicely with that of the rts. You for instance still want to have async I/O using the non-threaded rts. - change functions such as openFile to create handles using `FILE_FLAG_OVERLAPPED`. Especially the second one is not trivial. Getting IOCP support and/or RIO functionality in is actually fairly trivial, but if you don't change the internal encodings of base, you'll just take a hit by having it convert from UTF16 to UTF32 and back to UTF16. I am working on an implementation the other way, moving the I/O manager into Haskell and reworking most of base to use the right internal encoding for each platform. It's based on Joey's patches https://github.com/Mistuke /ghc-win-io-system was the state before merging into base. So We'll have a way to compare the two approaches then to see which is best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 09:35:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 09:35:21 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.a4e2e11ef0cc71f4c351342b50aedeb7@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I'm aware of your effort actually, it's here:[https://github.com/Mistuke /ghc-win-io-system/] isn't? And i'm sure you are an windows expert ;) The old `IODevice` typeclass is not satisfactory and i indeed want to define new one. The encoding problems in base use functions from C runtime on windows instead of using windows API directly, which is the culprit IMO. Because most of the windows API have wide-char version which can directly use UTF-16, isn't? But libuv really solved most of those problems VERY WELL. for example it mapped window console API to accept ansi escaped code, so we get colorful ansi terminal for free, and it does the heavy work to shim the UTF-16 encoded `readConsoleInputW/writeConsoleOutputW` to accept UTF-8 buffers, which reduced much of the headache. The real remaining problem is how to make libuv with with ghc's scheduler, which i think i have a plan, i describe it in the github link above, please have a look. Finally, if we can manage leverage libuv to do I/O in haskell, we can save lots of repeated work, libuv is really an all-in-one solution for I/O problems: tcp, pipes, process, file watchers, etc. You name it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 10:04:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 10:04:51 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.adc229c048830ebb38f7d34c6176f63c@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): It is reported that you can compile GHC 8 using {{{./configure --disable-large-address-space}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 10:28:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 10:28:58 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.48ba5b5a8ceaaa8aa786ee9b1d747f39@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 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 YitzGale): Due to #13304, this ticket isn't practical until either GHC HQ provides a bindist with {{{./configure --disable-large-address-space}}} or Microsoft fixes the WSL memory map bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 10:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 10:31:09 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.0e6b2f4772624b8b73550eb8f7a900bd@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by YitzGale): * related: => #13304 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 11:01:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 11:01:41 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.c7fc40148372beb23a5861b0a0128749@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): Does it work as expected in 8.0.2? I doubt this is related to atomic package database modification as afair nothing about the method of updating package.cache file has changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 11:10:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 11:10:16 -0000 Subject: [GHC] #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 Message-ID: <048.6d42a32a35eeefa9f253c2e47d4637e2@haskell.org> #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- __GLASGOW_HASKELL__ is 802 with ghc-8.2.1. {{{ #if __GLASGOW_HASKELL__ >= 803 thisShouldFail #endif }}} Does not fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 11:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 11:42:34 -0000 Subject: [GHC] #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 In-Reply-To: <048.6d42a32a35eeefa9f253c2e47d4637e2@haskell.org> References: <048.6d42a32a35eeefa9f253c2e47d4637e2@haskell.org> Message-ID: <063.371d92cfe147d7fba9d4353407173387@haskell.org> #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): 802 is parsed as x=8 yy=02, so it denotes 8.2, as per the specification https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html #standard-cpp-macros -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 11:52:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 11:52:30 -0000 Subject: [GHC] #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 In-Reply-To: <048.6d42a32a35eeefa9f253c2e47d4637e2@haskell.org> References: <048.6d42a32a35eeefa9f253c2e47d4637e2@haskell.org> Message-ID: <063.2eb42f9edc5d3897922f6f3c6b0b0adc@haskell.org> #14027: __GLASGOW_HASKELL__ / ProjectVersionInt is not set correctly in ghc 8.2.1 -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by choenerzs): * status: new => closed * resolution: => invalid Comment: Sorry, thanks for pointing out where I can find that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 14:06:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 14:06:58 -0000 Subject: [GHC] #14007: CI builds for integer-simple variant of GHC for Windows In-Reply-To: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> References: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> Message-ID: <060.5a6d9eda235337c6de322c92974e60ab@haskell.org> #14007: CI builds for integer-simple variant of GHC for Windows ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by varosi): Thanks! You're right, it's LGPL. But this means that either will be needed GHC built with dynamic linkage against this library, which will be harder to be distributed. And this doesn't solve that issue in easier way. Currently GHC is not binary distributed by default as a ready to use for proprietary production. May be this should be the title. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 14:08:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 14:08:16 -0000 Subject: [GHC] #14007: CI builds for integer-simple variant of GHC for Windows In-Reply-To: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> References: <045.df6f2cbe4660a6dd5578f06b0b1da371@haskell.org> Message-ID: <060.828dcdc5bce6c31108d2a4f9aa58dd67@haskell.org> #14007: CI builds for integer-simple variant of GHC for Windows ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by varosi): I know that "proprietary" is a bad word in open-source community. But as I know GHC is meant to be used in more wider context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 14:49:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 14:49:30 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.31d2d3111411756eba815e4190c7993b@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I suspect you are right; at this point I don't even think I own a machine that doesn't already have GHC installed. I'll try to setup a clean container and try installing there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 15:00:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 15:00:40 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) In-Reply-To: <048.aef8128a023635f337951aa397b7be20@haskell.org> References: <048.aef8128a023635f337951aa397b7be20@haskell.org> Message-ID: <063.16682644c68ac04aae16bfb8bd856e4f@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableSuperClasses 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: | -------------------------------------+------------------------------------- Comment (by simonpj): GHC's error message looks absolutely right to me. Writing in the kinds we have {{{ Functor :: forall c d. (c -> d) -> Constraint OnSnd :: forall c d. ((c,d) -> *) -> c -> d -> * class (Category c, Category d) => MyFunctor @c @d (f :: c -> d) where instance MyFunctor @(c,d) @* (f2 :: (c, d) -> *) => MyFunctor @d @* (OnSnd @c @d f2 (a::c)) where }}} From the instance declaration we are obliged to generate superclasses for `MyFunctor @d @* (OnSnd @c @d f2 (a::c))`, namely {{{ [W] Category d [W] Category * }}} The latter is no problem, but `Category d` is. What do we have available to prove it? Just the instance context {{{ [G] MyFunctor @(c,d) @* (f2 :: (c,d) -> *) }}} If we have that given, then we have its superclasses given: {{{ [G] Category (c,d) [G] Category * }}} Can we prove `Category d` given `Category (c,d)`? No we cannot. And that is just what GHC says. Here it is with `-fprint-explicit-kinds`: {{{ T14010.hs:45:10: error: * Could not deduce (Category d) arising from the superclasses of an instance declaration from the context: MyFunctor (c, d) * f2 bound by the instance declaration at T14010.hs:(45,10)-(46,31) }}} So I claim this is a non-bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 15:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 15:42:58 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.850d176d4ad77a54c0f4b63322b9743d@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: As noted in Phab:D3741, we need to reconsider the fix in comment:5. https://github.com/snowleopard/hadrian/issues/349 is also relevant here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 15:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 15:55:17 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.252a3f782b83c135f0f1e87a2ab0f888@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"88f20bdb60fb9469fa8ae953f7c2509d1913fdf7/ghc" 88f20bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="88f20bdb60fb9469fa8ae953f7c2509d1913fdf7" Add a caveat to the GHC.Generics examples about :+: nesting Summary: GHC's choice in how it nests `:+:` can sometimes affect the implementaiton of `GHC.Generics`-related code, so we should make a note of this in the examples we provide. Fixes #9453. Test Plan: Read it, like it, build it, ship it Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #9453 Differential Revision: https://phabricator.haskell.org/D3782 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 15:56:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 15:56:24 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.a18afdf450b0b2aa43a28070ebc2a9d6@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.8.2 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3782 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 16:42:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 16:42:36 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.c1045fc2228abc3aa17d83c11179cf49@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11645 Comment: This may be a duplicate of #11645 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:12:29 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.cf88c879f000621e57b365032e91bd10@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "ghc-stage2.hp.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:13:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:13:20 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.d3acb8ac4790add699ed93c04e5496e1@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Line 5418 on this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:32:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:32:04 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) In-Reply-To: <048.aef8128a023635f337951aa397b7be20@haskell.org> References: <048.aef8128a023635f337951aa397b7be20@haskell.org> Message-ID: <063.40e6ddfac59dcdd7074ad8c0c7c7385a@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableSuperClasses 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: | -------------------------------------+------------------------------------- Comment (by int-index): > Can we prove Category d given Category (c,d)? No we cannot. Yes, we can. The declaration of `Category` is `Super cat => Category cat`, so from `Category (c, d)` we can prove `Super (c, d)`, which reduces to `(Category c, Category d)`. Furthermore, if you study the original code that compiles, you can see that GHC manages to go via a similar route just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:39:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:39:30 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.c63872eb70e80d0b7f6d560acf1f64b6@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Running GHC with heap profiling and then running `hp2ps` on the result > gives > > {{{ > hp2ps: ghc-stage2.hp, line 17405, samples out of sequence > }}} > > Reproduction (GHC commit 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98) > > {{{ > cabal unpack skylighting-0.1.1.5 > cd skylighting-0.1.1.5 > cabal configure --with-ghc=$HOME/src/ghc-clean-july12/inplace/bin/ghc- > stage2 \ > --enable-profiling -fexecutable > cabal build > touch src/Skylighting/Syntax/Php.hs > > /home/dfeuer/src/ghc-clean-july12/inplace/bin/ghc-stage2 --make -i \ > -isrc -idist/build -O -prof -fprof-auto-exported -osuf p_o -hisuf \ > p_hi -optPdist/build/autogen/cabal_macros.h -hide-all-packages \ > -package-db dist/package.conf.inplace -package-id aeson-1.2.1.0 \ > -package base-4.10.0.0 -package blaze-html-0.9.0.1 -package \ > bytestring-0.10.8.2 -package case-insensitive-1.2.0.10 -package \ > containers-0.5.10.2 -package directory-1.3.0.2 -package \ > filepath-1.4.1.2 -package hxt-9.3.1.16 -package mtl-2.2.1 -package \ > regex-pcre-builtin-0.94.4.8.8.35 -package safe-0.3.15 -package \ > text-1.2.2.2 -package utf8-string-1.0.1.1 -XHaskell2010 \ > Skylighting.Types Skylighting.Regex \ > Skylighting.Tokenizer Skylighting.Syntax.Php -j1 +RTS \ > -s -h -N1 > > hp2ps ghc-stage2.hp > }}} New description: Running GHC with heap profiling and then running `hp2ps` on the result gives {{{ hp2ps: ghc-stage2.hp, line 17405, samples out of sequence }}} Reproduction (GHC commit 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98) {{{ cabal unpack skylighting-0.1.1.5 cd skylighting-0.1.1.5 cabal install --enable-profiling --only-dependencies -fexecutable cabal configure --with-ghc=$HOME/src/ghc-clean-july12/inplace/bin/ghc- stage2 \ --enable-profiling -fexecutable cabal build touch src/Skylighting/Syntax/Php.hs /home/dfeuer/src/ghc-clean-july12/inplace/bin/ghc-stage2 --make -i \ -isrc -idist/build -O -prof -fprof-auto-exported -osuf p_o -hisuf \ p_hi -optPdist/build/autogen/cabal_macros.h -hide-all-packages \ -package-db dist/package.conf.inplace -package-id aeson-1.2.1.0 \ -package base-4.10.0.0 -package blaze-html-0.9.0.1 -package \ bytestring-0.10.8.2 -package case-insensitive-1.2.0.10 -package \ containers-0.5.10.2 -package directory-1.3.0.2 -package \ filepath-1.4.1.2 -package hxt-9.3.1.16 -package mtl-2.2.1 -package \ regex-pcre-builtin-0.94.4.8.8.35 -package safe-0.3.15 -package \ text-1.2.2.2 -package utf8-string-1.0.1.1 -XHaskell2010 \ Skylighting.Types Skylighting.Regex \ Skylighting.Tokenizer Skylighting.Syntax.Php -j1 +RTS \ -s -h -N1 hp2ps ghc-stage2.hp }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:48:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:48:11 -0000 Subject: [GHC] #10064: Add support for "foo"## literals to MagicHash In-Reply-To: <049.cb303598e29d32fcc2ec0d8e38051be4@haskell.org> References: <049.cb303598e29d32fcc2ec0d8e38051be4@haskell.org> Message-ID: <064.9be6f07fc66a2beb5f34a34b6a01e260@haskell.org> #10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #5218 Comment: I think we should indeed treat this as a duplicate of #5218 as the answer proposed in comment:3 is precisely that which is being implemented in Phab:D2443. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 17:48:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 17:48:12 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) In-Reply-To: <048.aef8128a023635f337951aa397b7be20@haskell.org> References: <048.aef8128a023635f337951aa397b7be20@haskell.org> Message-ID: <063.0ed121e19788bd2d8d1fd38540b80a57@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableSuperClasses 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: | -------------------------------------+------------------------------------- Comment (by int-index): To clarify, you say that given {{{ [G] Functor @(c,d) @* (f2 :: (c,d) -> *) }}} we have its superclasses: {{{ [G] Category (c,d) [G] Category * }}} and you claim we can't prove `[W] Category d` from this. But with the definition of `Functor` that does compile, the superclasses are: {{{ [G] Category ((c,d), *) }}} and GHC will want to extract `[W] Category (d, *)` from it. So GHC appears to do more work here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 18:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 18:17:33 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c6748e8af5c2c71af2cb89d2d61eb68c@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmgrosen): * cc: jmgrosen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 20:43:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 20:43:16 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.53448dfb4ad86f9b43f653e730452233@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by bgamari): I'm honestly not sure *where* in the compiler it was determined that assembler output should be ISO 8859-1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 21:06:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 21:06:03 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.907adb4dd97321e0488844769ee3bcad@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Changes (by patrickdoc): * owner: (none) => patrickdoc Comment: The Sphinx tutorial on writing extensions is very similar to this: http ://shimizukawa-sphinx.readthedocs.io/en/latest/extdev/tutorial.html. That one just happens to use a list instead of a table. I'll see what I can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 23:10:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 23:10:03 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.052cf2e902e4d1ce25b0400cf8fc7e3e@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Strangely I've been unable to reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 23:26:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 23:26:46 -0000 Subject: [GHC] #13999: Simple function not inlined within declaration marked NOINLINE In-Reply-To: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> References: <042.05e754c872b86d798c391bd079d9b8a4@haskell.org> Message-ID: <057.88862c3b8894edf7895688ea959d8ac5@haskell.org> #13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by srb): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 23:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 23:36:19 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.716859e0e90e58d081466400bcce7460@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"85a295d5607b5f8015bb3517601ced0d1adc29ef/ghc" 85a295d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85a295d5607b5f8015bb3517601ced0d1adc29ef" ghc-prim: Don't allocate a thunk for each unpacked UTF-8 character While debugging #14005 I noticed that unpackCStringUtf8# was allocating a thunk for each Unicode character that it unpacked. This seems hardly worthwhile given that the thunk's closure will be at least three words, whereas the Char itself will be only two and requires only a bit of bit twiddling to construct. Test Plan: Validate Reviewers: simonmar, austin Subscribers: dfeuer, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3769 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 24 23:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Jul 2017 23:36:19 -0000 Subject: [GHC] #847: Threaded RTS problems on FreeBSD In-Reply-To: <047.3d44046f4bda82457dcb2c0744de1c9a@haskell.org> References: <047.3d44046f4bda82457dcb2c0744de1c9a@haskell.org> Message-ID: <062.146417884c85cd450f04ffbb361fff92@haskell.org> #847: Threaded RTS problems on FreeBSD -----------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.3 Component: Runtime System | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -----------------------------------+--------------------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"d8051c6cf08f02331f98fed7d5e88a95bd76e534/ghc" d8051c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8051c6cf08f02331f98fed7d5e88a95bd76e534" Use libpthread instead of libthr on FreeBSD Since #847 we have used libthr due to reported hangs with FreeBSD's KSE-based M:N pthread implementation. However, this was nearly 12 years ago and today libpthread seems to work fine. Moreover, adding -lthr to the linker flags break when used in conjunction with -r when gold is used (since -l and -r are incompatible although BFD ld doesn't complain). Test Plan: Validate on FreeBSD Reviewers: kgardas, austin Subscribers: rwbarton, thomie GHC Trac Issues: #847 Differential Revision: https://phabricator.haskell.org/D3773 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 01:06:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 01:06:51 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.4e8ffca2f79c5da431957c966333cd2a@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Phab:D3738 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ec7770886a23da86e59ddfa112dcc6b050d088c/ghc" 8ec77708/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ec7770886a23da86e59ddfa112dcc6b050d088c" testsuite: Add testcase for #13168 Thanks to Ryan Scott for the testcase. Currently broken. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 01:06:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 01:06:51 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.54bffd60b2a807378e6b1943abd37f40@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Phab:D3738 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2183ac16a98146bb673b5530ca154499a1c6166e/ghc" 2183ac16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2183ac16a98146bb673b5530ca154499a1c6166e" Fix import error with -XPackageImports when the module has a duplicate name Reviewers: austin, bgamari, mpickering Reviewed By: bgamari Subscribers: mpickering, rwbarton, thomie GHC Trac Issues: #13168 Differential Revision: https://phabricator.haskell.org/D3738 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 01:08:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 01:08:50 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.9fb7a85657c7dc2e4dc91362f51a7885@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Phab:D3738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks ak3n! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 13:29:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 13:29:15 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.3f945c99ed67372370acd84f07cf976c@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Comment (by takenobu): Thank you Ben. I add the correction information about Phab:D3784 to the following: * Equality proofs and deferred type errors (ICFP'12) * NEW: dreixel.net/research/pdf/epdtecp.pdf * OLD: www.microsoft.com/en-us/research/wp- content/uploads/2012/01/icfp12.pdf * OLD: research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/icfp12.pdf * OLD: research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 15:34:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 15:34:33 -0000 Subject: [GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d) In-Reply-To: <048.aef8128a023635f337951aa397b7be20@haskell.org> References: <048.aef8128a023635f337951aa397b7be20@haskell.org> Message-ID: <063.c3cd9bd0a4165e520541da06eeed3b4c@haskell.org> #14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableSuperClasses 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, you are right. It took me some time to recall. It's all described in this note, in `TcInstDcls`. {{{ Note [Recursive superclasses] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See Trac #3731, #4809, #5751, #5913, #6117, #6161, which all describe somewhat more complicated situations, but ones encountered in practice. See also tests tcrun020, tcrun021, tcrun033, and Trac #11427. ----- THE PROBLEM -------- The problem is that it is all too easy to create a class whose superclass is bottom when it should not be. Consider the following (extreme) situation: class C a => D a where ... instance D [a] => D [a] where ... (dfunD) instance C [a] => C [a] where ... (dfunC) Although this looks wrong (assume D [a] to prove D [a]), it is only a more extreme case of what happens with recursive dictionaries, and it can, just about, make sense because the methods do some work before recursing. To implement the dfunD we must generate code for the superclass C [a], which we had better not get by superclass selection from the supplied argument: dfunD :: forall a. D [a] -> D [a] dfunD = \d::D [a] -> MkD (scsel d) .. Otherwise if we later encounter a situation where we have a [Wanted] dw::D [a] we might solve it thus: dw := dfunD dw Which is all fine except that now ** the superclass C is bottom **! The instance we want is: dfunD :: forall a. D [a] -> D [a] dfunD = \d::D [a] -> MkD (dfunC (scsel d)) ... ----- THE SOLUTION -------- The basic solution is simple: be very careful about using superclass selection to generate a superclass witness in a dictionary function definition. More precisely: Superclass Invariant: in every class dictionary, every superclass dictionary field is non-bottom To achieve the Superclass Invariant, in a dfun definition we can generate a guaranteed-non-bottom superclass witness from: (sc1) one of the dictionary arguments itself (all non-bottom) (sc2) an immediate superclass of a smaller dictionary (sc3) a call of a dfun (always returns a dictionary constructor) The tricky case is (sc2). We proceed by induction on the size of the (type of) the dictionary, defined by TcValidity.sizeTypes. Let's suppose we are building a dictionary of size 3, and suppose the Superclass Invariant holds of smaller dictionaries. Then if we have a smaller dictionary, its immediate superclasses will be non-bottom by induction. What does "we have a smaller dictionary" mean? It might be one of the arguments of the instance, or one of its superclasses. Here is an example, taken from CmmExpr: class Ord r => UserOfRegs r a where ... (i1) instance UserOfRegs r a => UserOfRegs r (Maybe a) where (i2) instance (Ord r, UserOfRegs r CmmReg) => UserOfRegs r CmmExpr where For (i1) we can get the (Ord r) superclass by selection from (UserOfRegs r a), since it is smaller than the thing we are building (UserOfRegs r (Maybe a). But for (i2) that isn't the case, so we must add an explicit, and perhaps surprising, (Ord r) argument to the instance declaration. Here's another example from Trac #6161: class Super a => Duper a where ... class Duper (Fam a) => Foo a where ... (i3) instance Foo a => Duper (Fam a) where ... (i4) instance Foo Float where ... It would be horribly wrong to define dfDuperFam :: Foo a -> Duper (Fam a) -- from (i3) dfDuperFam d = MkDuper (sc_sel1 (sc_sel2 d)) ... dfFooFloat :: Foo Float -- from (i4) dfFooFloat = MkFoo (dfDuperFam dfFooFloat) ... Now the Super superclass of Duper is definitely bottom! This won't happen because when processing (i3) we can use the superclasses of (Foo a), which is smaller, namely Duper (Fam a). But that is *not* smaller than the target so we can't take *its* superclasses. As a result the program is rightly rejected, unless you add (Super (Fam a)) to the context of (i3). Note [Solving superclass constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ How do we ensure that every superclass witness is generated by one of (sc1) (sc2) or (sc3) in Note [Recursive superclasses]. Answer: * Superclass "wanted" constraints have CtOrigin of (ScOrigin size) where 'size' is the size of the instance declaration. e.g. class C a => D a where... instance blah => D [a] where ... The wanted superclass constraint for C [a] has origin ScOrigin size, where size = size( D [a] ). * (sc1) When we rewrite such a wanted constraint, it retains its origin. But if we apply an instance declaration, we can set the origin to (ScOrigin infinity), thus lifting any restrictions by making prohibitedSuperClassSolve return False. * (sc2) ScOrigin wanted constraints can't be solved from a superclass selection, except at a smaller type. This test is implemented by TcInteract.prohibitedSuperClassSolve * The "given" constraints of an instance decl have CtOrigin GivenOrigin InstSkol. * When we make a superclass selection from InstSkol we use a SkolemInfo of (InstSC size), where 'size' is the size of the constraint whose superclass we are taking. An similarly when taking the superclass of an InstSC. This is implemented in TcCanonical.newSCWorkFromFlavored }}} In this case we have {{{ We are making superclasses of: [W] Functor @d @* (OnSnd c d f2 a) Can we use superclasses of this? [G] Functor @((,) * * c d) @* f2 }}} The and the number of syntax nodes [G] is not smaller than that of [W], so we say "No". The relevant function is `TcSMonad.prohibitedSuperClassSolve`. We could perhaps "fix" this example by changing the size metric used for types. But then perhaps something else would go wrong. There is a workaround, as you observe. I wish I knew a better way. But, believe me, the convolutions to avoid generation superclasses that were accidentally bottom were MUCH worse before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 15:45:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 15:45:13 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.fd77c50b935899e38196d63e4c811a59@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11565 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That seems plausible. We could not call `isWorkerSmallEnough` if `sc_force` is true. Would you like to try that? If so, we should update this comnent {{{ ForceSpecConstr arguments are spotted in scExpr' and scTopBinds which then set sc_force to True when calling specLoop. This flag does four things: * Ignore specConstrThreshold, to specialise functions of arbitrary size (see scTopBind) * Ignore specConstrCount, to make arbitrary numbers of specialisations (see specialise) * Specialise even for arguments that are not scrutinised in the loop (see argToPat; Trac #4488) * Only specialise on recursive types a finite number of times (see is_too_recursive; Trac #5550; Note [Limit recursive specialisation]) }}} Now there'd be five things! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 15:55:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 15:55:00 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.12670768d276063db77f765231011163@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3743 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure it's a record wildcard problem? The Description doesn't have any record wildcards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 16:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 16:39:23 -0000 Subject: [GHC] #13904: LLVM does not need to trash caller-saved registers. In-Reply-To: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> References: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> Message-ID: <059.760bc8afb690a9878a3067a5a7ba6b90@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): Current patch is under the branch [http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T13904 wip/T13904]. Soon I will test/check the patch for the issues described in the related tickets to ensure there are no regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 16:48:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 16:48:56 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.aacd17ebfb15fd85b89c81398b416698@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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 simonpj): I have not worked all of this out, but I have learned something. You have this INLINE pragma: {{{ {-# INLINE mtlStateListParser_a #-} }}} It does nothing, because the function is recursive. But alas, it harms things a lot. Simply removing that INLINE pragma makes `mtlStateListParser_a` behave well in all settings, I think. Can you confirm that? I believe that the reason things go bad is this. GHC does this transformation (always): {{{ f = e |> co ===> f' = e f = f' |> co }}} Reason: `f` can now be inlined at all use sites, and `co` may cancel. But if the original `f` has an INLINE pragma we get {{{ f = e |> co { INLINE = } ===> f' = e f = f' |> co { INLINE = } }}} where the `{ INLINE = }` is the (stable, user-written) inlining for `f`. Now the point of the transformation is lost, becuase `f` won't be replaced at its use sites by `f' |> co`; the INLINE pragma is what gets inlined. Moreover, if `` and `e` both mention `f`, then `f` becomes a loop breaker and we get mutual recusion between `f` and `f'`. This what ultimately leads to the alternation between `(,)` and `(##)` you observed. Solution (I think) don't do this transformation if `f` has an INLINE pragma. I'll try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 17:07:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 17:07:37 -0000 Subject: [GHC] #13904: LLVM does not need to trash caller-saved registers. In-Reply-To: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> References: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> Message-ID: <059.3323f94f22a7d0ce5f4b8484e5121f48@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 17:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 17:30:41 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? Message-ID: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: ghc panic | Operating System: Linux impossible | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1. Compile an object file with -fPIC, e.g: {{{ cat > hello.c << EOF #include void hi(){puts("Hello, World!");} EOF gcc -c -fPIC hello.c }}} 2. Write Haskell that uses QuasiQuotes, e.g: {{{ cat > h.hs << EOF {-# LANGUAGE QuasiQuotes #-} import Text.Heredoc (here) s :: String s = [here|goes nothing|] EOF }}} 3. Compile with -fexternal-interpreter: {{{ cabal install heredoc ghc -fexternal-interpreter h.hs hello.o }}} I saw: [1 of 1] Compiling Main ( h.hs, h.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Loading temp shared object failed: /home/blynn/.local/lib/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc- prim-0.5.0.0-ghc8.0.2.so: undefined symbol: stg_thawArrayzh Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 17:31:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 17:31:04 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.bf0b2e052b3aebd0d36761b1bbe13760@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ghc panic | impossible 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: | -------------------------------------+------------------------------------- Changes (by blynn): * Attachment "h.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 17:31:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 17:31:17 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.4ddaeb69cc77e2163caf123a05f54cde@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ghc panic | impossible 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: | -------------------------------------+------------------------------------- Changes (by blynn): * Attachment "hello.c" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 17:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 17:31:27 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.4aa347433a176f88446031a96cf03027@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ghc panic | impossible 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: | -------------------------------------+------------------------------------- Changes (by blynn): * Attachment "Makefile" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 18:00:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 18:00:32 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal Message-ID: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Back in August 2016, David Feuer [https://mail.haskell.org/pipermail/libraries/2016-August/027293.html proposed] adding this function (originally from `lens`) to `Data.Functor`: {{{#!hs (<&>) :: Functor f => f a -> (a -> b) -> f b as <&> f = f <$> as infixl 1 <&> }}} The proposal was well received, so let's implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 18:25:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 18:25:55 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal Message-ID: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Template | Version: 8.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: -------------------------------------+------------------------------------- Back in September 2015, I [https://mail.haskell.org/pipermail/libraries/2015-September/026117.html proposed] using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 18:26:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 18:26:02 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.6855dfe072609e8582fba4f72c2c21f1@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.3 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 20:17:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 20:17:29 -0000 Subject: [GHC] #12801: Misleading error message when deriving Functor In-Reply-To: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> References: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> Message-ID: <059.c68145e682bde6972db0277661c5666d@haskell.org> #12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6bb32ba78580271921e3d5c3c98afac2c1b68de4/ghc" 6bb32ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6bb32ba78580271921e3d5c3c98afac2c1b68de4" Fix #10684 by processing deriving clauses with finer grain Summary: Previously, one could experience error cascades with deriving clauses when one class in a set of many failed to derive, causing the other derived classes to be skipped entirely and resulting in other errors down the line. The solution is to process each class in a data type's set of deriving clauses individually, and engineer it so that failure to derive an individual class within that set doesn't cancel out the others. Test Plan: make test TEST="T10684 T12801" Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #10684, #12801 Differential Revision: https://phabricator.haskell.org/D3771 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 20:17:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 20:17:29 -0000 Subject: [GHC] #10684: Error cascade when unrelated class derivation fails In-Reply-To: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> References: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> Message-ID: <060.7c0fbe1e0460d32907dac4cde8ce52da@haskell.org> #10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3771 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6bb32ba78580271921e3d5c3c98afac2c1b68de4/ghc" 6bb32ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6bb32ba78580271921e3d5c3c98afac2c1b68de4" Fix #10684 by processing deriving clauses with finer grain Summary: Previously, one could experience error cascades with deriving clauses when one class in a set of many failed to derive, causing the other derived classes to be skipped entirely and resulting in other errors down the line. The solution is to process each class in a data type's set of deriving clauses individually, and engineer it so that failure to derive an individual class within that set doesn't cancel out the others. Test Plan: make test TEST="T10684 T12801" Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #10684, #12801 Differential Revision: https://phabricator.haskell.org/D3771 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 20:18:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 20:18:43 -0000 Subject: [GHC] #10684: Error cascade when unrelated class derivation fails In-Reply-To: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> References: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> Message-ID: <060.8af750f62c4217dce8fee488cb97e0e8@haskell.org> #10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T10684 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3771 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_fail/T10684 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 20:19:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 20:19:34 -0000 Subject: [GHC] #12801: Misleading error message when deriving Functor In-Reply-To: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> References: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> Message-ID: <059.17170beff032406759b68967f56f8fd5@haskell.org> #12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | deriving/should_fail/T12801 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_fail/T12801 * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 20:45:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 20:45:12 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.30d477b0afd2fc56abc3c91fc64c6b78@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: ghc panic | impossible Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T14028 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * testcase: => T14028 * resolution: => fixed * milestone: => 8.2.1 Comment: This appears to be fixed in 8.2.1. Yay! See Phab:D3788 for testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 21:11:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 21:11:06 -0000 Subject: [GHC] #14018: Describe Frontend Plugin vs othe major mode differences in manual. In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.df90787602a4b649a4a324e4d63623d2@haskell.org> #14018: Describe Frontend Plugin vs othe major mode differences in manual. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 literon): For the record, I wrote up some warts of calling GHC API multiple times at https://gist.github.com/robinp/49c68c6f69f6aabfddee3cba42b4964f. The current state favors Frontend Plugin due to the global linker state, if robust compilation is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 21:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 21:12:32 -0000 Subject: [GHC] #14018: Highlight differences of Frontend Plugin vs GHC API (was: Describe Frontend Plugin vs othe major mode differences in manual.) In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.ca2bcdc52620410735a74c06d119bd1f@haskell.org> #14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 21:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 21:43:34 -0000 Subject: [GHC] #14018: Highlight differences of Frontend Plugin vs GHC API In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.b9d5103f0a9312a56234461481b03809@haskell.org> #14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 simonpj): > For the record, I wrote up some warts of calling GHC API multiple times Thank you. Would you consider adding it to GHC's user-contributed documentation, here [https://wiki.haskell.org/GHC/As_a_library]? Better still, can we clean up those warts somehow? Eg shoudl the linker state be as global as it is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:02:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:02:25 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used Message-ID: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **"The linker search path problem"** It's common these days to have 400 (transitive) Hackage dependencies (even my hobby projects have that many). When linking, statically or dynamically, GHC passes `-L /path/to/foo/dir` and `-L HSfoo...` to the linker for each Haskell package `foo`. That results in `N` many linker search paths (`-L`) and `M` many library names. That will translate in `N * M` many `stat()` syscalls (file existence checks) in the linker to check where each file is. For 400 package dependencies, that translates to 160k `stat()` syscalls. On my machine (on SSD and hot file system cache in RAM), that takes `0.7 seconds` (measured with `strace -c -w`). That is a substantial overhead for linking (for example, the executable with 400 dependencies with which I found this problem can be linked with `ld.gold` in just 1.5 seconds). If there is tooling in between GHC and the linker that also parses linker flags and checks for file existence (for example Nix's `cc-wrapper` and `ld-wrapper` scripts, or other instrumentation or build system tooling, which are often not written in compiled languages and thus [https://github.com/NixOS/nixpkgs/issues/27609 much slower] at stat()ing than the linker is), then the problem can be easily blown up another 10x. As a result, you may be waiting a lot longer for your link to finish than necessary. For static linking, this could be resolved by passing the archive files (`libHSfoo....a`) directly to the linker instead of the `-L`/`-l` combination. For this we would need to check that passing files directly really have the same semantics as `-L` and `-l`, but the man pages suggest so (and I'll check it with the binutils authors). For dynamic linking, it cannot be fixed this way. It can be fixed at compile time, but with dynamic linking the same problem exists at run-time (startup): Here all the `-L`s become `RPATH`s if not installed in a global location (for example, nix has an `RPATH` for each package), and thus program startup can take up to those 0.7 seconds I mentioned. To solve the runtime problem, the only solution seems to be to place the libraries into the same directory (i.e. to have `M = 1` essentially). This approach (putting all libs into 1 directory) would also solve it for the static linking case, with the drawback of this being not compatible with how cabal sandboxes, stack build and snapshot dirs, nix, Debian and other distributions deliver and build libraries. And for some of them this approach goes straight against their nature. **Detail discussion:** See below the relevant discussion on #ghc: {{{ nh2: bgamari-: do you know why ghc uses -L and -l for linking libHS... things instead of passing the .a file directly? hvr: nh2: btw, fun fact: on IBM AIX, both static and DSOs are stored in .a archives bgamari-: nh2, I suspect just since it makes the dynamic and static linking codepaths consistent hvr: nh2: and if you use .a for linking, you end up hardwiring the DSO path into your executable nh2: bgamari-: I'm looking into whether it would make sense to change it, at least for the platforms that would support it, because the (-L * -l) searching that it does currently seems to dominate link times here nh2: cc hvr hvr: nh2: sounds reasonable; but then you end up with longer CLI arguments hvr: nh2: it could be a problem for when the tools don't support @ bgamari-: nh2, seriously? bgamari-: the search is really that long? bgamari-: nh2, it seems like that's a linker bug hvr: bgamari-: I guess it depends on how many -L there are bgamari-: nh2, how many libraries are you linking against? hvr: bgamari-: as each -L and -l multiply w/ each other requiring several stat() calls iirc bgamari-: hvr, yes hvr: but otoh, I wouldn't expect this to *dominate* linker times bgamari-: right bgamari-: hvr, this is the compile-time equivalent to #11587 bgamari-: which I still think we should do hvr: right bgamari-: hmm bgamari-: although comment:9 sort of suggests that this is already the case for user-installed libraries ***bgamari- forgot about that hvr: I mean, if you have really *many* -L-paths hvr: then the quadratic effect becomes probably significant bgamari-: right bgamari-: nh2, how many libraries are you linking against? nh2: bgamari-: I have approximately L=450 and l=350. There is some notoriously slow tooling "in between" that I'm currently investigating, namely nix's ld-wrapper, which does does the stat'ing in bash, where statting that many files easily takes 1 second, but I did a quick test with `xargs ls -1` on the "$DIR/lib${name}.a" expansion, an that too takes 1 second, so it might not be entirely its fault hvr: ok, ~400 is quite a bit bgamari-: sheesh bgamari-: yes, that is... impressive geekosaur: next they'll want this to work on macOS >.. geekosaur: >.> hvr: and then windows! nh2: even my hobby projects have 300 recursive deps by now nh2: bgamari-: my strace says that `ls` did the 160k stat()s in 0.7 seconds, which is half of the time that `gold` needs to link my binary nh2: bgamari-: I have now strace'd `ld` itself, that does it slightly faster, 0.5 seconds, but this is just because it's my hobby project and has "only" that many deps; for a real project that'd be 2 seconds just stat()ing bgamari-: nh2, sheesh nh2: bgamari-: of course nix's ld wrapper, being written in bash, does the same thing but at least 5x slower bgamari-: nh2, do you just add all of Hackage to your build-depends? ;) bgamari-: nh2, Instead of passing explicit paths I think I would rather just put all of the archives in LIBDIR nh2: bgamari-: I blame it on my dependees ;) also, "Haskell has high-quality libraries and encourages code reuse" comes back at us here bgamari-: although, admittedly, I haven't really thought through the consequences of this yet bgamari-: this does sound like a worthwhile thing to fix though bgamari-: that is a significant amount of time nh2: bgamari-: personally I'd WAY prefer explicit args vs env vars because then I can see them in ps, I can easily replay the specific command myself to debug it etc hvr: nh2: not every library on Hackage is "high-quality" ;-) bgamari-: I had always assumed that our large linking times we due to, well, the "linking" bgamari-: not just the stating bgamari-: nh2, fair enough, but I'd rather not have to add even more platform-dependent behavior to our interaction with the system toolchain bgamari-: oh, wait bgamari-: nh2, I didn't mean to pass via env var bgamari-: nh2, I just meant pass one -L bgamari-: nh2, where the static and dynamic libraries can both be bgamari-: found nh2: bgamari-: I don't know that, where can I read about that? Is it a flag? bgamari-: nh2, -L? bgamari-: it's just the usual --library-path flag nh2: bgamari-: I got confused by LIBDIR in caps bgamari-: ah bgamari-: right, I should have been more specific nh2: bgamari-: so what do you mean by that, somehow put all the libraries into a single dir? bgamari-: nh2, treat static archives the same way we treat dynamic libraries bgamari-: which is to place them in, e.g., $HOME/.cabal/lib/$ghc_version/ bgamari-: instead of where they are currently, $HOME/.cabal/lib/$ghc_version/$library_abi_name bgamari-: then you can just pass -L$HOME/.cabal/lib/$ghc_version to ld bgamari-: and a -l for each library bgamari-: I think this is probably as much a Cabal change as it is a GHC change nh2: bgamari-: that doesn't seem to go well with approaches that package separately, like debian, nix, cabal sandboxes and stack work dirs hvr: which includes new-build bgamari-: I'm not sure it's fundamentally incompatible hvr: yeah, but it's a lot of work to change everyone :-) bgamari-: to take the case of new-build, all that matters AFAIK is that the packages are registered in separate package dbs bgamari-: there's nothing stopping you from throwing all of the libraries into one directory hvr: bgamari-: well, I kinda exploit that new-build has nicely self-contained folders hvr: this makes it easier to atomically move around artifacts nh2: bgamari-: do you have a dislike for passing them explicitly as files beyond cross-platform worries? Because I really find explicit arguments the cleanest, easiest and most debuggable approach hvr: as I can stage the new artifact, and then move it into place hvr: atomically hvr: by simply renaming/moving the folder which contains everyting bgamari-: nh2, I'm just currently really not sure that passing libraries by path is really equivalent to passing via -l hvr: unfortauntely filesytems don't offer many other facilities for atomic transactions bgamari-: I would need to run some experiments nh2: bgamari-: gcc's and ld's man pages suggest that to me, looking at their respective `-l`; we certainly should double check (or maybe simpler, ask the linker authors) bgamari-: if we can really show that the linker treats explicit paths no differently then I'd be okay with it nh2: suggests that they are equivalent) bgamari-: but I'm rather weary bgamari-: nh2, are you only suggesting this for static libraries? geekosaur: it's supposed to be equivalent. but shared objects have the added issue of runtime discoverability (i.e. passing by full path at link time does not install a full path for runtime access) geekosaur: except on macos or older aix where it's always a full path) nh2: bgamari-: no, at least the stat()-taking-time problem is the same problem for .so's (though I'm using static linking in many places and would be appreciate an improvement even if limited to static linking) bgamari-: nh2, the problem is that your approach doesn't help dynamic linkage at all bgamari-: since the runtime linker still needs to search N paths bgamari-: so I would argue that new-build, stack, etc. really should be putting libraries in the same directory regardless bgamari-: more work or not bgamari-: it's the only way to truly solve the problem mpickering: Wonders if David saw this issue https://github.com/haskell/cabal/issues/4550 alanz: mpickering: what are you planning to use the source plugins for? nh2: bgamari-: yeah you're right, the start-up cost of the executable will always be there for dynamic linking, I was purely talking from the compiler's perspective bgamari-: nh2, my point was that I would prefer to solve the problem once and for all bgamari-: rather than have another sharp edge that we then still need to solve bgamari-: given that moving the libraries solves both problems, it feels like the right solution mpickering: alanz: haskell-indexer was the plan nh2: bgamari-: I agree that for dynamic linking that is the only solution. But I'm not sure there exist a fits-it-all solution across static and dynamic. At least for my work, I'd prefer to have static libs that can be anywhere, in nix-style immutable locations, and give up on dynamic linking (of Haskell libs) to get that. It seems that hvr's thoughts are going in the same direction on the cabal side, and lots of build system and OS movements these days seem to converge away from global shared dirs to dir-prefixes. nh2: I also suspect that static linking will be even more attractive now that sensible -split-sections is in place, which can give smaller code sizes, which .so's can't deliver. nh2: So I'm not sure that a big shift to the fits-it-all solution that satisfies dynamic linking needs would be the most practical or used; it'd certainly be nice to have it for dynamic linking, but I'm not sure all the downstreams can be forced to do it that way for non-static if it quite fundamentally dictates how they have to work. If they can, it would probably take pretty long. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:06:17 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.52bfd0111388e965184d060bbaffec35@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11587 Comment: This is essentially the compile-time equivalent of #11587. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:06:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:06:52 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.28dfb5ad9902a127a5c6ce7123b77761@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12031 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12031 Comment: We have this same problem with static libraries and compile-time linking. See #14031. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:18:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:18:10 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.cfda7026c30edbe9e91e4ab15a17dc46@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): There is more info from `sphalerite` on `#nixos` on the topic of dynamic linking. Apparently it ''is'' possible to give "default locations" for .so files, instead of using RPATHs: {{{ sphalerite[m]: I opened an issue about that (linking through absolute paths rather than rpath) a couple of months back https://github.com/NixOS/nixpkgs/issues/24844 it's possible, just not implemented sphalerite[m]: on linux that is -- on macOS it's already done through absolute paths nh2: that's excellent news, can you give me a short summary of what I have to do to give it an explicit path? Also, will the resulting link just be a "hint", so still be overridable with LD_LIBRARY_PATH? sphalerite[m]: It's not implemented in nixpkgs's machinery yet, so you'd need to pass absolute paths to the linker manually instead of using `-l` sphalerite[m]: and no, it would not be overridable using LD_LIBRARY_PATH at that point. LD_PRELOAD would still work though. sphalerite[m]: That stuff is all discussed in the issue comments though nh2: I'm getting a bit lost in the amount of comments; what feature/flags to ld is the magic that has this effect? sphalerite[m]: passing absolute paths instead of -lXYZ sphalerite[m]: so rather than -lreadline, /nix/store/...-readline-1.2.3/lib/libreadline.so.12345 nh2: ah, so passing explicit .so to `ld` doesn't do the same as `-l` does, but instead makes it do this "default path link"? I always assumed `-l` just finds files and then passes them normally (or so at least `man ld` suggests) sphalerite[m]: Yeah no, it's not the same sphalerite[m]: Huh, actually they seem to be producing the same result for me in a test I did just now }}} [https://github.com/NixOS/nixpkgs/issues/24844 This nix issue] discusses the mentioned approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:28:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:28:01 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.45a3ca48ff60ec449cb183f6f6ea4e9b@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): {{{ nh2: and in the case where the "hinted" so location doesn't exist, what does it do, does it then search the search paths? sphalerite[m]: no. It's not a hint, it's "the library is here". It's "if the library is not here this program will not run." nh2: hmm OK. So that approach only works if you really know ahead of time where the lib will be }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 25 22:38:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Jul 2017 22:38:48 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.53168d32c7d85a78dfc2ef2c327a3bd9@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I forgot to mention, `gold` has an optimisation that trades the `stat()` against reading the directory contents; this makes it much faster at the problem and theoretically avoids the `N * M` complexity. However, it's not an all-round solution because it can be slower when the directories are very large / contain files we don't care about -- we'd read those only to throw them away. So it's essentially changing the the problem into `N * (number of total files in each N)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 01:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 01:35:45 -0000 Subject: [GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces Message-ID: <050.88678544262d43e8177c20f56750d292@haskell.org> #14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 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: -------------------------------------+------------------------------------- Spun off from #13799 (and https://ghc.haskell.org/trac/ghc/ticket/13054#comment:2). This code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} infix 5 :*: data a :*: b = a :*: b }}} But this code does not: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} $([d| infix 5 :*: data a :*: b = a :*: b |]) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc -ddump-splices Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:(4,3)-(6,6): Splicing declarations [d| infix 5 :*:_anM, :*:_anL data a_anN :*:_anL b_anO = a_anN :*:_anM b_anO |] ======> infix 5 :*:_a3IL infix 5 :*:_a3IK data (:*:_a3IK) a_a3IM b_a3IN = a_a3IM :*:_a3IL b_a3IN Bug.hs:4:3: error: Multiple fixity declarations for ‘:*:_a3IL’ also at Bug.hs:(4,3)-(6,6) | 4 | $([d| infix 5 :*: | ^^^^^^^^^^^^^^^... }}} Inspecting the `-ddump-splices` output reveals why: when `infix 5 :*:` is renamed, because `:*:` refers to two different names in both the value and type namespaces, it actually gets renamed to `infix 5 :*:_anM, :*:_anL`, where `:*:_anM` and `:*:_anL` are the same name with different uniques. Normally, this isn't a problem, since feeding `infix 5 :*:_anM, :*:_anL` to the typechecker works fine. However, when it's spliced in via Template Haskell, it gets fed back into the renamer, where it believes that `:*:_anM` and `:*:_anL` are duplicate names, causing the error. Really, this is just a symptom of the fact that infix declarations are insufficiently powerful to encode information for identical names in different namespaces. But until GHC gains this ability, we need to find some workaround for this problem. My hunch is that we'll need to give GHC the power to recognize these sorts of duplicate fixity declarations in `Convert` and only emit one actual fixity declaration per set of duplicates. (Disclaimer: I haven't worked out all the fiddly details yet.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 01:36:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 01:36:06 -0000 Subject: [GHC] #13799: -ddump-splices prints out declarations in the wrong order In-Reply-To: <050.f45d5f324cc6583163c58bb2b6f6629d@haskell.org> References: <050.f45d5f324cc6583163c58bb2b6f6629d@haskell.org> Message-ID: <065.0a8138d4681a8ec193d3ef06bf2a1cfa@haskell.org> #13799: -ddump-splices prints out declarations in the wrong order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: Upon further thought, I don't think this is a feasible thing to do. The problem is that by the time we have enough info for `-ddump-splices` to print out anything, the source has long since been renamed, and with renaming comes dependency analysis, which possibly results in declaration reordering as seen above. We could consider plumbing through the pre- renamed source to be printed as well, but that's a lot of wiring for very little gain. On the other hand, the fact that you can't splice a quoted thing with an `infix` declaration for two names in different namespaces is a very real, but separate bug. I've opened #14032 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 01:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 01:42:58 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.9e6e7e7b7b71ab38a464447bdc513e9c@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): I've given this some further thought, and my belief is that `newName` really can't be made to work well with top-level identifier names. After all, if you have two top-level foreign imports with the name `makeFun` and you try invoking `makeFun` somewhere, how is GHC supposed to tell the two `makeFun`s apart, even with different uniques? `newName` just doesn't work for that purpose. Now perhaps you don't care about having a foreign import with the exact name `makeFun`—you just want a unique top-level name that sorta kinda looks like `makeFun` (perhaps, say, `makeFun_4j121c4`). I think there is a valid need for such functionality, and in fact, I think Richard's `newUniqueName` provides more or less a blueprint for how one might actually implement it in GHC. I propose adapting the implementation to create a `newGlobalName` function for this purpose. Moreover, I propose we note the fact that `newName` is insufficient for top-level names in its Haddocks, and point to `newGlobalName` as an example of how you should do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 01:44:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 01:44:07 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.5e5b8da2a9f0f27978a8ae5866436583@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 02:28:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 02:28:15 -0000 Subject: [GHC] #13968: TH gives "Illegal binding of built-in syntax" error In-Reply-To: <050.3732828496226ff6565e5d73754050f2@haskell.org> References: <050.3732828496226ff6565e5d73754050f2@haskell.org> Message-ID: <065.5969d2cdae8bc80248ce76f2600e633f@haskell.org> #13968: TH gives "Illegal binding of built-in syntax" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3789 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3789 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 05:41:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 05:41:40 -0000 Subject: [GHC] #14033: Invalid newtype causes GHC to panic rather than fail to compile Message-ID: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> #14033: Invalid newtype causes GHC to panic rather than fail to compile -------------------------------------+------------------------------------- Reporter: | Owner: (none) InThisStyle10s6p | 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: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE TypeFamilies #-} newtype Zero = Zero newtype Succ a = Succ a type family Add n m :: * where Add Zero m = m Add (Succ n) m = Succ (Add n m) }}} causes the following GHC error: {{{ $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon Zero }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 07:32:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 07:32:27 -0000 Subject: [GHC] #14018: Highlight differences of Frontend Plugin vs GHC API In-Reply-To: <046.d609cac0996bcde01452ff40a359a835@haskell.org> References: <046.d609cac0996bcde01452ff40a359a835@haskell.org> Message-ID: <061.3b0cb0a5a5308d4192ae3eb1b61ff716@haskell.org> #14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 literon): Could do the writeup once the problem / solution crystallizes. It's not clear to me yet that (not) unloading non-Haskell objects is a fundamental limitation or just a missing feature. I was looking around, and for the uneducated sight the problem seems to be this: `preload_static` [1] in Linker.hs (called eventually by `loadCmdLineLibs`) calls either `dynLoadObjs` or `loadObj`, depending on `dynamicGHC`. But neither of those do any bookkeeping for `PersistentLinkerState`. It seems calling `dynLinkObjs` [2] (note `Link` not `Load` in name) would be more appropriate, since it updates the `objs_loaded` in `PLS`, so a later `unload` call could unload those as well. This sounds more in line with the Linker comment that `PLS` should be synced with the C linker state. However `dynLinkObjs`, while morally doing the same as `preload_static` + accounting, conditionally chooses `dynLoadObjs` or `loadObj` based on `dynamicInterpreter`. Latter seems to be defined the same as `dynamicGhc` except if an external interpreter is used, which I have no idea about. It would be insightful if someone knowledgeable about the linker code could comment if this has good reasons and a change is not feasible, or maybe is just historic leftover. [1]: http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=472 [2]: http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=854 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 08:06:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 08:06:28 -0000 Subject: [GHC] #14033: Invalid newtype causes GHC to panic rather than fail to compile In-Reply-To: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> References: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> Message-ID: <070.563e816b279643f0abcfd07b88c97285@haskell.org> #14033: Invalid newtype causes GHC to panic rather than fail to compile -------------------------------------+------------------------------------- Reporter: InThisStyle10s6p | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Happily it's ok in HEAD {{{ T14033.hs:5:16: error: • The constructor of a newtype must have exactly one field but ‘Zero’ has none • In the definition of data constructor ‘Zero’ In the newtype declaration for ‘Zero’ | 5 | newtype Zero = Zero | ^ }}} I think a dup of #13271. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:34:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:34:02 -0000 Subject: [GHC] #14033: Invalid newtype causes GHC to panic rather than fail to compile In-Reply-To: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> References: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> Message-ID: <070.311da8627e70a33be08449777c83ff21@haskell.org> #14033: Invalid newtype causes GHC to panic rather than fail to compile -------------------------------------+------------------------------------- Reporter: InThisStyle10s6p | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d31181b90cff7c791465687377cd2093627df429/ghc" d31181b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d31181b90cff7c791465687377cd2093627df429" Test Trac #14033 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:34:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:34:01 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.e86cb962f931ce3c8c1cf36b846b7204@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"75bf11c037d9e82f95ac9779bfd2b1432835bd76/ghc" 75bf11c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75bf11c037d9e82f95ac9779bfd2b1432835bd76" Fix binder visiblity for default methods Trac #13998 showed that default methods were getting bogus tyvar binder visiblity info; and that it matters in the code genreated by the default-method fill-in mechanism * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders with the right visibility info by getting TyConBinders from the class TyCon. (Previously we made up visiblity info, but that caused #13998.) * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder] which can build correct forall binders for a) default methods (Trac #13998) b) data constructors This was originally BuildTyCl.mkDataConUnivTyVarBinders * Move mkTyVarBinder, mkTyVarBinders from Type to Var }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:35:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:35:46 -0000 Subject: [GHC] #14005: Explore moving from pretty to prettyprinter In-Reply-To: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> References: <046.00a7ed7516b897a5e7cf99ebffe5bc6d@haskell.org> Message-ID: <061.1679ed08ab89a491aebead4e43331204@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by mpickering): Now that this patch builds, it is also necessary to patch haddock which uses the old interface for pretty in the latex backend. https://github.com/mpickering/haddock/tree/wip/T14005 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:38:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:38:48 -0000 Subject: [GHC] #13998: Default Signature messes up arity of type constructor In-Reply-To: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> References: <049.74f19eb2704c4dbdc34ecb9c2763deea@haskell.org> Message-ID: <064.4219eff3591ebb04a79ed04049afc9fe@haskell.org> #13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T13998 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T13998 * resolution: => fixed Comment: OK, done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:47:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:47:59 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.cee2be6f4aab0b5c5a817b4b7fd83fc7@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 simonpj): I'm not convinced yet. Expanding the API for TH is ok, but it complicates the user model. Let's see. This conversation concerns top-level declarations. I can see two use-cases * Functions or data types that are used locally (in some other function or data type), but not really exported. * Functions or data types that are exported. For the former, it's in implementation shortcoming that `newName` does not work (e.g. comment:2). For the latter, for it to be useful importing module needs to know the name, so exporting (say) `makeFun_4j121c4` and `makeFun_4j12137` is not helpful. So maybe the latter is a non-use-case. If it's just the former I think we should be able to make it "just work". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 11:56:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 11:56:54 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.400301ecae0bcae3f0a6c6d993fb0c84@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 12:27:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 12:27:06 -0000 Subject: [GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces In-Reply-To: <050.88678544262d43e8177c20f56750d292@haskell.org> References: <050.88678544262d43e8177c20f56750d292@haskell.org> Message-ID: <065.0968071d331f843079975997d7debffe@haskell.org> #14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 goldfire): I'm not feeling like adding yet another ghc-proposal to my queue at the moment, but this really should be fixed at the language level. I propose `type infix 5 :*:` to mean a fixity declaration on a type, and then to deprecate and eventually eliminate the current behavior of a fixity declaration that applies to both levels simultaneously (while respecting the 3-release policy). If you (meaning ''you'', the reader of this comment) agree and have the time, make this into a proper proposal! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 12:35:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 12:35:01 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.56e5098dc5e0760e13ec542d95d774ab@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 goldfire): Agreed with comment:5. `newName`s should not be exportable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 12:37:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 12:37:11 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.79982e9eebc61e403b856ddabc041c5d@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer 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 supersven): Would it make sense to commit this as a small proposal to https://prime.haskell.org/, too? The Haskell Report 2010 and Prime are very sparse when it comes to Functors (only stating the laws). E.g. https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1320006.3.5 But I think it would be reasonable to get the functions of "core" (i.e. base) type classes standardized. :) What to you think about this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 13:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 13:31:49 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.a2e6e602bead9ebd50bd51765607c139@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): I also agree that `newName`s should not be exportable! Moreover, I don't think you really should be exporting `newGlobalName`s either—but that doesn't mean it's a non-use-case! Quite often in Template Haskell code you'll want to define top-level functions that are used across other functions. For example, in my [http://hackage.haskell.org/package /deriving-compat-0.3.6/docs/Data-Enum-Deriving.html deriving-compat] library, I've found myself wanting to define a function: {{{#!hs con2tagFoo :: Foo -> Int# }}} Like what happens when you derive `Enum` in GHC today, only in Template Haskell. This needs to be a top-level identifier, however, since `con2tag` functions also get used across multiple `Enum` methods, so I need to ensure that this `con2TagFoo` name is globally unique. However, it certainly doesn't need to be exported. Currently, the only way to do this is with something like `newUniqueName` from comment:2, which isn't robust against things like infix names. I imagine tim-m89's use case would also be served by `newGlobalName`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 13:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 13:33:45 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.54f46730948e6f2dd1a65a7443433971@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer 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 RyanGlScott): If you want to submit a separate proposal about this, then my all means go for it. But I think that's well out of the scope of this ticket, which simply aims to add a function to the `Data.Functor` module, and we certainly don't need to go through the Prime committee for just that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 13:40:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 13:40:55 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.fde538a653e0337026facf8ec3e97cd2@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer 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 supersven): Okay. Thanks for your fast response! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 13:49:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 13:49:59 -0000 Subject: [GHC] #14033: Invalid newtype causes GHC to panic rather than fail to compile In-Reply-To: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> References: <055.1fa4b4bfb99fd73a7c9cbc89b7f23f96@haskell.org> Message-ID: <070.9826a8cb28618badc5a41e77f19d5a56@haskell.org> #14033: Invalid newtype causes GHC to panic rather than fail to compile -------------------------------------+------------------------------------- Reporter: InThisStyle10s6p | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_fail/T14033 Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => indexed-types/should_fail/T14033 * resolution: => duplicate * related: => #13271 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 13:54:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 13:54:46 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.03b5727be99c2fa1a8c9e0a106b44ad6@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3743 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yeah. The original code was minimized too much: it triggered a panic, but the code wouldn't have typechecked anyway (like #12063). They gave a second repro which does involve record wildcards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 15:03:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 15:03:17 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.8acb32d624d3922da1c3af9b738fb02e@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc3 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 danilo2): @simon, you are right. Removing `INLINE` makes these two functions run with fine performance. It is already described in point 8 in the ticket description. Please note, that point 8 tells about probably related problem with INLINABLE pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 15:38:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 15:38:13 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.90ff5cd0fce0eac263de6f55b443a5d8@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is where we stand on this: This bug seeks to address the fact that we currently have few good ways of encoding literal strings verbatim (e.g. as raw, unchanged bytes) in object code. This is because we insist on encoding primitive strings as null- terminated modified UTF-8. This means that things like `bytestring` and `text` have a rather complicated and inefficient handling of these literals. This inefficiency stems from two reasons, * One needs to look for and correctly handle the U+0000 codepoints (encoded as `0xc0 0x80`) in the primitive string * It's impossible to know what the length of the string is without walking it The solution here is to rework our desugaring of primitive strings such that, {{{#!hs "hello"# }}} Will be desugared as, {{{#!hs let x = "hello"# :: Addr# in (# 5#, "hello"# #) }}} This means that we can encode the string contents in plain UTF-8 without a NULL terminator. The type of `unpackCString#` then becomes, {{{#!hs unpackCString# :: (# Int#, Addr# #) -> String }}} and the implementation gets a tiny bit simpler (since it simply decodes a fixed number of bytes, instead of looking for a NULL). Consequently, libraries can then provide rules matching on `unpackCString#` applications, replacing them with what is essentially `memcpy`. This is for the most part a simple change, with the exception being GHCi support due to the need for unboxed tuples. jscholl started implementing this nearly a year ago but stalled. I recently rebased his work (Phab:D2443) and addressed several of the issues that came up in review. Unfortunately currently GHCi segmentation faults, which will take some to work out. Note that are two related problems that this does not address, * pure ASCII literals (which might be used to, for instance, encode a binary representation of a static `Array`) * `ByteArray#` literals, as requested in ticket:11312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 16:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 16:33:22 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.75f4830faad1082970e002c60e9d8e7c@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 simonpj): > I need to ensure that this `con2TagFoo` name is globally unique. Indeed. So shouldn't `newName` work for that purpose? Presumably it doesn't, but wouldn't it be nicer for our users if it did? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 16:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 16:43:34 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.c3690e6e182b2d1b77c768efbc30df33@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): I don't see how `newName` could possibly be made to work for this purpose. The problem is that after you splice in a Template Haskell splice (in `Convert`), it has to be fed back into the renamer. But `newName` is designed to keep the same original name (just with a different unique), so the renamer will rightly reject multiple top-level things named `con2Tag`, even if they were produced via `newName`, as there's no good way to disambiguate them. Now, you might object "but RyanGlScott, just disambiguate them by their uniques!" That's all well and good, but disambiguating by uniques is really a strategy that I can only envision working in the internals of GHC. The problem is that there are adversarial users who will want to abuse the fact that `newName` can now be used to create top-level names. For instance, what happens if a user tries this? {{{#!hs {-# LANGUAGE TemplateHaskell #-} $(splice1) -- produces top-level function named con2Tag $(splice2) -- produces top-level function named con2Tag uhOh = con2Tag }}} Here, `con2Tag` is written using surface syntax, where we don't have the power to refer to the unique of the particular `con2Tag` we want. The only sensible thing I can see doing in this situation is to error. To avoid this hornet's nest of tricky design questions, I propose we not try to retrofit the ability to create top-level names onto `newName`, but instead create a different function for this purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 17:44:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 17:44:32 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.1d5d8788a679159d1346931ffdf303b1@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Based on the date, it appears this ticket likely refers to `fltkhs-0.4.0.9` (commit 60ace4c5e7743f5a24ac959fba877aeb27d80618) from June 25, 2016. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 18:25:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 18:25:41 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.8b53bf5c5248ffc49d4a87fb34fe78f6@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): This is still reproducible from the latest [https://hackage.haskell.org/package/fltkhs-0.5.3.4 FLTKHS] with GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 19:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 19:09:39 -0000 Subject: [GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces In-Reply-To: <050.88678544262d43e8177c20f56750d292@haskell.org> References: <050.88678544262d43e8177c20f56750d292@haskell.org> Message-ID: <065.615a150b62b54917c84c74f1b2bf72e1@haskell.org> #14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott Comment: I'll draft up a proposal when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 19:15:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 19:15:28 -0000 Subject: [GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo Message-ID: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I'm filing this a sa proxy for user `sam2_` from IRC: {{{ $ cat Bug.hs {-# LANGUAGE ApplicativeDo #-} module Bug where doc = do () <- a () <- b c' <- c return d }}} {{{ $ ghc-8.2.1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: out of memory (requested 1048576 bytes) }}} {{{ $ ghc-8.0.2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Variable not in scope: a :: f () Bug.hs:6:9: error: Variable not in scope: b :: f () Bug.hs:7:9: error: Variable not in scope: c :: f a0 Bug.hs:8:10: error: Variable not in scope: d }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 20:41:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 20:41:26 -0000 Subject: [GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo In-Reply-To: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> References: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> Message-ID: <057.bfcef85c8ce8e39f64efbffa94c606f2@haskell.org> #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by nh2): {{{ sam2_: I'd just like to note that this also happens to valid code; the undefined names aren't essential to reproduction }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 20:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 20:45:06 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.dedc8641a76d7fb815273513df35e6de@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I asked the `binutils` upstream question here: https://sourceware.org/ml/binutils/2017-07/msg00296.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 21:17:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 21:17:46 -0000 Subject: [GHC] #13968: TH gives "Illegal binding of built-in syntax" error In-Reply-To: <050.3732828496226ff6565e5d73754050f2@haskell.org> References: <050.3732828496226ff6565e5d73754050f2@haskell.org> Message-ID: <065.c98fb8d7193ad26241856f61ba013181@haskell.org> #13968: TH gives "Illegal binding of built-in syntax" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3789 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"d774b4e2de4f07d2432b67010305fede7aeefc78/ghc" d774b4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d774b4e2de4f07d2432b67010305fede7aeefc78" Fix #13968 by consulting isBuiltInOcc_maybe Summary: We were unconditionally reporting `Illegal binding of built-in syntax` in an error message, but this error doesn't make sense in certain Template Haskell scenarios which can trigger it. Let's give a more sensible error message by first checking if the name we're binding really is built-in syntax, using the handy `isBuiltInOcc_maybe` function. Test Plan: make test TEST=T13968 Reviewers: bgamari, austin, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13968 Differential Revision: https://phabricator.haskell.org/D3789 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 26 21:18:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Jul 2017 21:18:49 -0000 Subject: [GHC] #13968: TH gives "Illegal binding of built-in syntax" error In-Reply-To: <050.3732828496226ff6565e5d73754050f2@haskell.org> References: <050.3732828496226ff6565e5d73754050f2@haskell.org> Message-ID: <065.8d3936a77f555b971a39e35c7e148d3b@haskell.org> #13968: TH gives "Illegal binding of built-in syntax" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: th/T13968 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3789 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T13968 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:33:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:33:04 -0000 Subject: [GHC] #14035: Weird performance results. Message-ID: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. The first "part" of it I've described here: https://ghc.haskell.org/trac/ghc/ticket/14013 (and I will be referring to this issue later), however there are some other problems that do not seem directly connected to 14013 ticket. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached.** The code is a pseudo-parser implementation. It consumes any char in a loop and fails on empty input in the end. \\ == Helpers Let's define 2 helpers: {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} dotl :: (b -> c) -> (a -> b) -> a -> c dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} }}} So whenever we see `.` in code it is strict in all of its arguments. \\ == Strict StateT performance improvement Let's consider following code: {{{#!hs import qualified Control.Monad.State.Strict as S newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving (Applicative, Functor, Monad, MonadTrans) class MonadState s m | m -> s where get :: m s put :: s -> m () runStateT :: forall s m a. StateT s m a -> s -> m (a, s) evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT #-} evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT #-} instance Monad m => MonadState s (StateT s m) where get = StateT S.get ; {-# INLINE get #-} put = StateT . S.put ; {-# INLINE put #-} }}} There are few non-obvious things to note here: 1. This wrapper performs about **15 TIMES better** than `Control.Monad.State.Strict.StateT` (in the provided examples) and if we create a loop in pure code imitating a parser, this `StateT` gets completely optimized away, while the `mtl`'s version does not. 2. If we replace the following functions with lazy composition, we get the same, high performance: {{{#!hs runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} }}} 3. However, if we slightly change the `evalStateT`, we've got the bad performance, equals to the `mtl`'s `StateT` version (15 times slower): {{{#!hs evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} }}} It's a very strange result, especially that `evalStateT` is used only once in the code while running the tests. \\ == Strict Either & EitherT The code contains a very minimalistic implementation of `Either` and `EitherT` in order to make their definitions and utils strict. These definitions are copy-pasted and simplified (removed unused code) from: https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html \\ == Strict Bool and tuple Moreover we define strict Bool `or` operation and 2-element tuple with strict arguments: {{{#!hs data T a b = T !a !b deriving (Generic, Show, Functor) data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} }}} \\ == Parser implementation All the above declarations were simple helpers compiled with `-XStrict`, because available libraries do not provide them for us. This code is a "real" use case and shows the weird performance results. The parser implementation is simple: {{{#!hs newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b a <- ma T !b' a' <- fromFailParser $ f a return $! T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} instance MonadTrans (FailParser) where lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} }}} We use `undefined` for non-important functions. The parser is `EitherT` wrapper: Left happens when we failed parsing input, while Right otherwise. The `XBool` denotes if we made any progress (so after consuming a letter it is set to `XTrue`). There are some additional util functions, like `returnProgress` which behaves just like return, but also sets the `XBool` value to `XTrue`: {{{#!hs instance Monad m => MonadProgressParser (FailParser m) where returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE returnProgress #-} -- In correct code it should be XTrue as described below. }}} In the provided code, there is `XFalse` used instead of `XTrue` because of some interesting observations: 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| b') a'` above, so it does NOT affect the way the program logically executes it's body. 2. Both `b` and `b'` are strict and fully evaluated. 3. If both `b` and `b'` are `XFalse` (as in the provided code, they always are `XFalse`) we get a good performance. In order to test it, the above code contains `XFalse` instead of `XTrue`. 4. If we use the correct version of `returnProgress` as described just before point 1 above, we get 15 times slower performance (the same or very similar to the one when used altered `evalStateT` definition). We could try to explain it: maybe Haskell was able to optimize code if it discovered, there always were only `XFalse` values used and after the change there are both `XTrue` and `XFalse`, so it really has to run the `(|||)` operator. This way of thinking fails as fast as we check that changing `XFalse` to `XTrue` **everywhere** in the code give us again bad performance. 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we get good performance, while replacing it with `return $! T b a'` give us bad performance. It does not make any sense, because both `b` and `b'` are strict and fully evaluated. Moreover, it is the only place in code where they are used. 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' ||| b) a'` does NOT change the performance (we are getting the good one). == Final notes We've been talking with some people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. In fact we started to be worried a lot about how we can use Haskell for high-performance parts at all if it is not obvious if a very simple changes do not affect performance so much, like changing `evalStateT m = fmap fst . runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times slowdown. It makes the code both very fragile to any changes as well as makes it unmaintainable. Tracking performance in a very small program (like the attached one) is possible, while tracking it in bigger one, taking in considerating the described problems, make it almost impossible. I'm writing this because I'm worried about where these problems originate from and I would really like to solve them / know why they appear and be sure we can continue to use Haskell for our high-performance demanding applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:33:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:33:53 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.b3f0c2b23ca5e0a704e464a180424af0@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by danilo2): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:35:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:35:18 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.e7452d11f5110be1c5a238b0691a9c19@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! I was recently testing performance of a critical code in a product we > are shipping and I'm getting really weird results. The first "part" of it > I've described here: https://ghc.haskell.org/trac/ghc/ticket/14013 (and I > will be referring to this issue later), however there are some other > problems that do not seem directly connected to 14013 ticket. > > **The code is compiled with `-XStrict` enabled globally. The full source > code for this ticket is attached.** > The code is a pseudo-parser implementation. It consumes any char in a > loop and fails on empty input in the end. > > \\ > > == Helpers > > Let's define 2 helpers: > {{{#!hs > (.) :: (b -> c) -> (a -> b) -> a -> c > (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} > > dotl :: (b -> c) -> (a -> b) -> a -> c > dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} > }}} > > So whenever we see `.` in code it is strict in all of its arguments. > > \\ > > == Strict StateT performance improvement > > Let's consider following code: > {{{#!hs > import qualified Control.Monad.State.Strict as S > > newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving > (Applicative, Functor, Monad, MonadTrans) > > class MonadState s m | m -> s where > get :: m s > put :: s -> m () > > runStateT :: forall s m a. StateT s m a -> s -> m (a, s) > evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a > runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT > #-} > evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT > #-} > > instance Monad m => MonadState s (StateT s m) where > get = StateT S.get ; {-# INLINE get #-} > put = StateT . S.put ; {-# INLINE put #-} > }}} > > There are few non-obvious things to note here: > 1. This wrapper performs about **15 TIMES better** than > `Control.Monad.State.Strict.StateT` (in the provided examples) and if we > create a loop in pure code imitating a parser, this `StateT` gets > completely optimized away, while the `mtl`'s version does not. > > 2. If we replace the following functions with lazy composition, we get > the same, high performance: > {{{#!hs > runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} > evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} > }}} > > 3. However, if we slightly change the `evalStateT`, we've got the bad > performance, equals to the `mtl`'s `StateT` version (15 times slower): > {{{#!hs > evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} > }}} > > It's a very strange result, especially that `evalStateT` is used only > once in the code while running the tests. > > \\ > > == Strict Either & EitherT > > The code contains a very minimalistic implementation of `Either` and > `EitherT` in order to make their definitions and utils strict. These > definitions are copy-pasted and simplified (removed unused code) from: > https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html > https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html > > \\ > > == Strict Bool and tuple > > Moreover we define strict Bool `or` operation and 2-element tuple with > strict arguments: > > {{{#!hs > data T a b = T !a !b deriving (Generic, Show, Functor) > > data XBool = XTrue | XFalse deriving (Show, Generic) > > (|||) :: XBool -> XBool -> XBool > (|||) !a !b = case a of > XTrue -> a > XFalse -> b > {-# INLINE (|||) #-} > }}} > > \\ > > == Parser implementation > > All the above declarations were simple helpers compiled with `-XStrict`, > because available libraries do not provide them for us. This code is a > "real" use case and shows the weird performance results. > > The parser implementation is simple: > {{{#!hs > newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T > XBool a) } deriving (Functor) > > instance Monad m => Applicative (FailParser m) where > pure = undefined > (<*>) = undefined > > instance Monad m => Monad (FailParser m) where > return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} > FailParser ma >>= f = FailParser $ do > T !b a <- ma > T !b' a' <- fromFailParser $ f a > return $! T (b ||| b') a' > {-# INLINE (>>=) #-} > _ >> _ = undefined ; {-# INLINE (>>) #-} > > instance MonadTrans (FailParser) where > lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} > }}} > > We use `undefined` for non-important functions. The parser is `EitherT` > wrapper: Left happens when we failed parsing input, while Right > otherwise. The `XBool` denotes if we made any progress (so after > consuming a letter it is set to `XTrue`). There are some additional util > functions, like `returnProgress` which behaves just like return, but also > sets the `XBool` value to `XTrue`: > > {{{#!hs > instance Monad m => MonadProgressParser (FailParser m) where > returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE > returnProgress #-} -- In correct code it should be XTrue as described > below. > }}} > > In the provided code, there is `XFalse` used instead of `XTrue` because > of some interesting observations: > > 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| > b') a'` above, so it does NOT affect the way the program logically > executes it's body. > > 2. Both `b` and `b'` are strict and fully evaluated. > > 3. If both `b` and `b'` are `XFalse` (as in the provided code, they > always are `XFalse`) we get a good performance. In order to test it, the > above code contains `XFalse` instead of `XTrue`. > > 4. If we use the correct version of `returnProgress` as described just > before point 1 above, we get 15 times slower performance (the same or > very similar to the one when used altered `evalStateT` definition). We > could try to explain it: maybe Haskell was able to optimize code if it > discovered, there always were only `XFalse` values used and after the > change there are both `XTrue` and `XFalse`, so it really has to run the > `(|||)` operator. This way of thinking fails as fast as we check that > changing `XFalse` to `XTrue` **everywhere** in the code give us again bad > performance. > > 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we > get good performance, while replacing it with `return $! T b a'` give us > bad performance. It does not make any sense, because both `b` and `b'` > are strict and fully evaluated. Moreover, it is the only place in code > where they are used. > > 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' > ||| b) a'` does NOT change the performance (we are getting the good one). > > == Final notes > > We've been talking with some people - both in the company I'm working in > as well as on IRC and we do not see any reason why this code behaves in > this way and why it is so sensitive to the changes. In fact we started to > be worried a lot about how we can use Haskell for high-performance parts > at all if it is not obvious if a very simple changes do not affect > performance so much, like changing `evalStateT m = fmap fst . runStateT > m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times > slowdown. It makes the code both very fragile to any changes as well as > makes it unmaintainable. Tracking performance in a very small program > (like the attached one) is possible, while tracking it in bigger one, > taking in considerating the described problems, make it almost > impossible. I'm writing this because I'm worried about where these > problems originate from and I would really like to solve them / know why > they appear and be sure we can continue to use Haskell for our high- > performance demanding applications. New description: Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. The first "part" of it I've described here: https://ghc.haskell.org/trac/ghc/ticket/14013 (and I will be referring to this issue later), however there are some other problems that do not seem directly connected to 14013 ticket. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached.** The code is a pseudo-parser implementation. It consumes any char in a loop and fails on empty input in the end. Everything was compiled with following options (and many variations): `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. \\ == Helpers Let's define 2 helpers: {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} dotl :: (b -> c) -> (a -> b) -> a -> c dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} }}} So whenever we see `.` in code it is strict in all of its arguments. \\ == Strict StateT performance improvement Let's consider following code: {{{#!hs import qualified Control.Monad.State.Strict as S newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving (Applicative, Functor, Monad, MonadTrans) class MonadState s m | m -> s where get :: m s put :: s -> m () runStateT :: forall s m a. StateT s m a -> s -> m (a, s) evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT #-} evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT #-} instance Monad m => MonadState s (StateT s m) where get = StateT S.get ; {-# INLINE get #-} put = StateT . S.put ; {-# INLINE put #-} }}} There are few non-obvious things to note here: 1. This wrapper performs about **15 TIMES better** than `Control.Monad.State.Strict.StateT` (in the provided examples) and if we create a loop in pure code imitating a parser, this `StateT` gets completely optimized away, while the `mtl`'s version does not. 2. If we replace the following functions with lazy composition, we get the same, high performance: {{{#!hs runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} }}} 3. However, if we slightly change the `evalStateT`, we've got the bad performance, equals to the `mtl`'s `StateT` version (15 times slower): {{{#!hs evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} }}} It's a very strange result, especially that `evalStateT` is used only once in the code while running the tests. \\ == Strict Either & EitherT The code contains a very minimalistic implementation of `Either` and `EitherT` in order to make their definitions and utils strict. These definitions are copy-pasted and simplified (removed unused code) from: https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html \\ == Strict Bool and tuple Moreover we define strict Bool `or` operation and 2-element tuple with strict arguments: {{{#!hs data T a b = T !a !b deriving (Generic, Show, Functor) data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} }}} \\ == Parser implementation All the above declarations were simple helpers compiled with `-XStrict`, because available libraries do not provide them for us. This code is a "real" use case and shows the weird performance results. The parser implementation is simple: {{{#!hs newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b a <- ma T !b' a' <- fromFailParser $ f a return $! T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} instance MonadTrans (FailParser) where lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} }}} We use `undefined` for non-important functions. The parser is `EitherT` wrapper: Left happens when we failed parsing input, while Right otherwise. The `XBool` denotes if we made any progress (so after consuming a letter it is set to `XTrue`). There are some additional util functions, like `returnProgress` which behaves just like return, but also sets the `XBool` value to `XTrue`: {{{#!hs instance Monad m => MonadProgressParser (FailParser m) where returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE returnProgress #-} -- In correct code it should be XTrue as described below. }}} In the provided code, there is `XFalse` used instead of `XTrue` because of some interesting observations: 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| b') a'` above, so it does NOT affect the way the program logically executes it's body. 2. Both `b` and `b'` are strict and fully evaluated. 3. If both `b` and `b'` are `XFalse` (as in the provided code, they always are `XFalse`) we get a good performance. In order to test it, the above code contains `XFalse` instead of `XTrue`. 4. If we use the correct version of `returnProgress` as described just before point 1 above, we get 15 times slower performance (the same or very similar to the one when used altered `evalStateT` definition). We could try to explain it: maybe Haskell was able to optimize code if it discovered, there always were only `XFalse` values used and after the change there are both `XTrue` and `XFalse`, so it really has to run the `(|||)` operator. This way of thinking fails as fast as we check that changing `XFalse` to `XTrue` **everywhere** in the code give us again bad performance. 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we get good performance, while replacing it with `return $! T b a'` give us bad performance. It does not make any sense, because both `b` and `b'` are strict and fully evaluated. Moreover, it is the only place in code where they are used. 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' ||| b) a'` does NOT change the performance (we are getting the good one). == Final notes We've been talking with some people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. In fact we started to be worried a lot about how we can use Haskell for high-performance parts at all if it is not obvious if a very simple changes do not affect performance so much, like changing `evalStateT m = fmap fst . runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times slowdown. It makes the code both very fragile to any changes as well as makes it unmaintainable. Tracking performance in a very small program (like the attached one) is possible, while tracking it in bigger one, taking in considerating the described problems, make it almost impossible. I'm writing this because I'm worried about where these problems originate from and I would really like to solve them / know why they appear and be sure we can continue to use Haskell for our high-performance demanding applications. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:37:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:37:45 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by danilo2): * Attachment "Main.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:37:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:37:45 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.b86c816a1655ca231014d9d13a13a6ab@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by danilo2): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:41:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:41:08 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.2d1aeae544c7e63ca7f86582eee61b61@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! I was recently testing performance of a critical code in a product we > are shipping and I'm getting really weird results. The first "part" of it > I've described here: https://ghc.haskell.org/trac/ghc/ticket/14013 (and I > will be referring to this issue later), however there are some other > problems that do not seem directly connected to 14013 ticket. > > **The code is compiled with `-XStrict` enabled globally. The full source > code for this ticket is attached.** > The code is a pseudo-parser implementation. It consumes any char in a > loop and fails on empty input in the end. > > Everything was compiled with following options (and many variations): > `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. > > \\ > > == Helpers > > Let's define 2 helpers: > {{{#!hs > (.) :: (b -> c) -> (a -> b) -> a -> c > (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} > > dotl :: (b -> c) -> (a -> b) -> a -> c > dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} > }}} > > So whenever we see `.` in code it is strict in all of its arguments. > > \\ > > == Strict StateT performance improvement > > Let's consider following code: > {{{#!hs > import qualified Control.Monad.State.Strict as S > > newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving > (Applicative, Functor, Monad, MonadTrans) > > class MonadState s m | m -> s where > get :: m s > put :: s -> m () > > runStateT :: forall s m a. StateT s m a -> s -> m (a, s) > evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a > runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT > #-} > evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT > #-} > > instance Monad m => MonadState s (StateT s m) where > get = StateT S.get ; {-# INLINE get #-} > put = StateT . S.put ; {-# INLINE put #-} > }}} > > There are few non-obvious things to note here: > 1. This wrapper performs about **15 TIMES better** than > `Control.Monad.State.Strict.StateT` (in the provided examples) and if we > create a loop in pure code imitating a parser, this `StateT` gets > completely optimized away, while the `mtl`'s version does not. > > 2. If we replace the following functions with lazy composition, we get > the same, high performance: > {{{#!hs > runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} > evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} > }}} > > 3. However, if we slightly change the `evalStateT`, we've got the bad > performance, equals to the `mtl`'s `StateT` version (15 times slower): > {{{#!hs > evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} > }}} > > It's a very strange result, especially that `evalStateT` is used only > once in the code while running the tests. > > \\ > > == Strict Either & EitherT > > The code contains a very minimalistic implementation of `Either` and > `EitherT` in order to make their definitions and utils strict. These > definitions are copy-pasted and simplified (removed unused code) from: > https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html > https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html > > \\ > > == Strict Bool and tuple > > Moreover we define strict Bool `or` operation and 2-element tuple with > strict arguments: > > {{{#!hs > data T a b = T !a !b deriving (Generic, Show, Functor) > > data XBool = XTrue | XFalse deriving (Show, Generic) > > (|||) :: XBool -> XBool -> XBool > (|||) !a !b = case a of > XTrue -> a > XFalse -> b > {-# INLINE (|||) #-} > }}} > > \\ > > == Parser implementation > > All the above declarations were simple helpers compiled with `-XStrict`, > because available libraries do not provide them for us. This code is a > "real" use case and shows the weird performance results. > > The parser implementation is simple: > {{{#!hs > newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T > XBool a) } deriving (Functor) > > instance Monad m => Applicative (FailParser m) where > pure = undefined > (<*>) = undefined > > instance Monad m => Monad (FailParser m) where > return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} > FailParser ma >>= f = FailParser $ do > T !b a <- ma > T !b' a' <- fromFailParser $ f a > return $! T (b ||| b') a' > {-# INLINE (>>=) #-} > _ >> _ = undefined ; {-# INLINE (>>) #-} > > instance MonadTrans (FailParser) where > lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} > }}} > > We use `undefined` for non-important functions. The parser is `EitherT` > wrapper: Left happens when we failed parsing input, while Right > otherwise. The `XBool` denotes if we made any progress (so after > consuming a letter it is set to `XTrue`). There are some additional util > functions, like `returnProgress` which behaves just like return, but also > sets the `XBool` value to `XTrue`: > > {{{#!hs > instance Monad m => MonadProgressParser (FailParser m) where > returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE > returnProgress #-} -- In correct code it should be XTrue as described > below. > }}} > > In the provided code, there is `XFalse` used instead of `XTrue` because > of some interesting observations: > > 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| > b') a'` above, so it does NOT affect the way the program logically > executes it's body. > > 2. Both `b` and `b'` are strict and fully evaluated. > > 3. If both `b` and `b'` are `XFalse` (as in the provided code, they > always are `XFalse`) we get a good performance. In order to test it, the > above code contains `XFalse` instead of `XTrue`. > > 4. If we use the correct version of `returnProgress` as described just > before point 1 above, we get 15 times slower performance (the same or > very similar to the one when used altered `evalStateT` definition). We > could try to explain it: maybe Haskell was able to optimize code if it > discovered, there always were only `XFalse` values used and after the > change there are both `XTrue` and `XFalse`, so it really has to run the > `(|||)` operator. This way of thinking fails as fast as we check that > changing `XFalse` to `XTrue` **everywhere** in the code give us again bad > performance. > > 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we > get good performance, while replacing it with `return $! T b a'` give us > bad performance. It does not make any sense, because both `b` and `b'` > are strict and fully evaluated. Moreover, it is the only place in code > where they are used. > > 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' > ||| b) a'` does NOT change the performance (we are getting the good one). > > == Final notes > > We've been talking with some people - both in the company I'm working in > as well as on IRC and we do not see any reason why this code behaves in > this way and why it is so sensitive to the changes. In fact we started to > be worried a lot about how we can use Haskell for high-performance parts > at all if it is not obvious if a very simple changes do not affect > performance so much, like changing `evalStateT m = fmap fst . runStateT > m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times > slowdown. It makes the code both very fragile to any changes as well as > makes it unmaintainable. Tracking performance in a very small program > (like the attached one) is possible, while tracking it in bigger one, > taking in considerating the described problems, make it almost > impossible. I'm writing this because I'm worried about where these > problems originate from and I would really like to solve them / know why > they appear and be sure we can continue to use Haskell for our high- > performance demanding applications. New description: Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached.** The code is a pseudo-parser implementation. It consumes any char in a loop and fails on empty input in the end. Everything was compiled with following options (and many variations): `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. \\ == Helpers Let's define 2 helpers: {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} dotl :: (b -> c) -> (a -> b) -> a -> c dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} }}} So whenever we see `.` in code it is strict in all of its arguments. \\ == Strict StateT performance improvement Let's consider following code: {{{#!hs import qualified Control.Monad.State.Strict as S newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving (Applicative, Functor, Monad, MonadTrans) class MonadState s m | m -> s where get :: m s put :: s -> m () runStateT :: forall s m a. StateT s m a -> s -> m (a, s) evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT #-} evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT #-} instance Monad m => MonadState s (StateT s m) where get = StateT S.get ; {-# INLINE get #-} put = StateT . S.put ; {-# INLINE put #-} }}} There are few non-obvious things to note here: 1. This wrapper performs about **15 TIMES better** than `Control.Monad.State.Strict.StateT` (in the provided examples) and if we create a loop in pure code imitating a parser, this `StateT` gets completely optimized away, while the `mtl`'s version does not. 2. If we replace the following functions with lazy composition, we get the same, high performance: {{{#!hs runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} }}} 3. However, if we slightly change the `evalStateT`, we've got the bad performance, equals to the `mtl`'s `StateT` version (15 times slower): {{{#!hs evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} }}} It's a very strange result, especially that `evalStateT` is used only once in the code while running the tests. \\ == Strict Either & EitherT The code contains a very minimalistic implementation of `Either` and `EitherT` in order to make their definitions and utils strict. These definitions are copy-pasted and simplified (removed unused code) from: https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html \\ == Strict Bool and tuple Moreover we define strict Bool `or` operation and 2-element tuple with strict arguments: {{{#!hs data T a b = T !a !b deriving (Generic, Show, Functor) data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} }}} \\ == Parser implementation All the above declarations were simple helpers compiled with `-XStrict`, because available libraries do not provide them for us. This code is a "real" use case and shows the weird performance results. The parser implementation is simple: {{{#!hs newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b a <- ma T !b' a' <- fromFailParser $ f a return $! T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} instance MonadTrans (FailParser) where lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} }}} We use `undefined` for non-important functions. The parser is `EitherT` wrapper: Left happens when we failed parsing input, while Right otherwise. The `XBool` denotes if we made any progress (so after consuming a letter it is set to `XTrue`). There are some additional util functions, like `returnProgress` which behaves just like return, but also sets the `XBool` value to `XTrue`: {{{#!hs instance Monad m => MonadProgressParser (FailParser m) where returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE returnProgress #-} -- In correct code it should be XTrue as described below. }}} In the provided code, there is `XFalse` used instead of `XTrue` because of some interesting observations: 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| b') a'` above, so it does NOT affect the way the program logically executes it's body. 2. Both `b` and `b'` are strict and fully evaluated. 3. If both `b` and `b'` are `XFalse` (as in the provided code, they always are `XFalse`) we get a good performance. In order to test it, the above code contains `XFalse` instead of `XTrue`. 4. If we use the correct version of `returnProgress` as described just before point 1 above, we get 15 times slower performance (the same or very similar to the one when used altered `evalStateT` definition). We could try to explain it: maybe Haskell was able to optimize code if it discovered, there always were only `XFalse` values used and after the change there are both `XTrue` and `XFalse`, so it really has to run the `(|||)` operator. This way of thinking fails as fast as we check that changing `XFalse` to `XTrue` **everywhere** in the code give us again bad performance. 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we get good performance, while replacing it with `return $! T b a'` give us bad performance. It does not make any sense, because both `b` and `b'` are strict and fully evaluated. Moreover, it is the only place in code where they are used. 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' ||| b) a'` does NOT change the performance (we are getting the good one). == Final notes We've been talking with some people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. In fact we started to be worried a lot about how we can use Haskell for high-performance parts at all if it is not obvious if a very simple changes do not affect performance so much, like changing `evalStateT m = fmap fst . runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times slowdown. It makes the code both very fragile to any changes as well as makes it unmaintainable. Tracking performance in a very small program (like the attached one) is possible, while tracking it in bigger one, taking in considerating the described problems, make it almost impossible. I'm writing this because I'm worried about where these problems originate from and I would really like to solve them / know why they appear and be sure we can continue to use Haskell for our high-performance demanding applications. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 00:49:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 00:49:40 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.79cf39e635d8b4e8094d4486566d1b14@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! I was recently testing performance of a critical code in a product we > are shipping and I'm getting really weird results. > > **The code is compiled with `-XStrict` enabled globally. The full source > code for this ticket is attached.** > The code is a pseudo-parser implementation. It consumes any char in a > loop and fails on empty input in the end. > > Everything was compiled with following options (and many variations): > `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. > > \\ > > == Helpers > > Let's define 2 helpers: > {{{#!hs > (.) :: (b -> c) -> (a -> b) -> a -> c > (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} > > dotl :: (b -> c) -> (a -> b) -> a -> c > dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} > }}} > > So whenever we see `.` in code it is strict in all of its arguments. > > \\ > > == Strict StateT performance improvement > > Let's consider following code: > {{{#!hs > import qualified Control.Monad.State.Strict as S > > newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving > (Applicative, Functor, Monad, MonadTrans) > > class MonadState s m | m -> s where > get :: m s > put :: s -> m () > > runStateT :: forall s m a. StateT s m a -> s -> m (a, s) > evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a > runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT > #-} > evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT > #-} > > instance Monad m => MonadState s (StateT s m) where > get = StateT S.get ; {-# INLINE get #-} > put = StateT . S.put ; {-# INLINE put #-} > }}} > > There are few non-obvious things to note here: > 1. This wrapper performs about **15 TIMES better** than > `Control.Monad.State.Strict.StateT` (in the provided examples) and if we > create a loop in pure code imitating a parser, this `StateT` gets > completely optimized away, while the `mtl`'s version does not. > > 2. If we replace the following functions with lazy composition, we get > the same, high performance: > {{{#!hs > runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} > evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} > }}} > > 3. However, if we slightly change the `evalStateT`, we've got the bad > performance, equals to the `mtl`'s `StateT` version (15 times slower): > {{{#!hs > evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} > }}} > > It's a very strange result, especially that `evalStateT` is used only > once in the code while running the tests. > > \\ > > == Strict Either & EitherT > > The code contains a very minimalistic implementation of `Either` and > `EitherT` in order to make their definitions and utils strict. These > definitions are copy-pasted and simplified (removed unused code) from: > https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html > https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html > > \\ > > == Strict Bool and tuple > > Moreover we define strict Bool `or` operation and 2-element tuple with > strict arguments: > > {{{#!hs > data T a b = T !a !b deriving (Generic, Show, Functor) > > data XBool = XTrue | XFalse deriving (Show, Generic) > > (|||) :: XBool -> XBool -> XBool > (|||) !a !b = case a of > XTrue -> a > XFalse -> b > {-# INLINE (|||) #-} > }}} > > \\ > > == Parser implementation > > All the above declarations were simple helpers compiled with `-XStrict`, > because available libraries do not provide them for us. This code is a > "real" use case and shows the weird performance results. > > The parser implementation is simple: > {{{#!hs > newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T > XBool a) } deriving (Functor) > > instance Monad m => Applicative (FailParser m) where > pure = undefined > (<*>) = undefined > > instance Monad m => Monad (FailParser m) where > return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} > FailParser ma >>= f = FailParser $ do > T !b a <- ma > T !b' a' <- fromFailParser $ f a > return $! T (b ||| b') a' > {-# INLINE (>>=) #-} > _ >> _ = undefined ; {-# INLINE (>>) #-} > > instance MonadTrans (FailParser) where > lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} > }}} > > We use `undefined` for non-important functions. The parser is `EitherT` > wrapper: Left happens when we failed parsing input, while Right > otherwise. The `XBool` denotes if we made any progress (so after > consuming a letter it is set to `XTrue`). There are some additional util > functions, like `returnProgress` which behaves just like return, but also > sets the `XBool` value to `XTrue`: > > {{{#!hs > instance Monad m => MonadProgressParser (FailParser m) where > returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE > returnProgress #-} -- In correct code it should be XTrue as described > below. > }}} > > In the provided code, there is `XFalse` used instead of `XTrue` because > of some interesting observations: > > 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| > b') a'` above, so it does NOT affect the way the program logically > executes it's body. > > 2. Both `b` and `b'` are strict and fully evaluated. > > 3. If both `b` and `b'` are `XFalse` (as in the provided code, they > always are `XFalse`) we get a good performance. In order to test it, the > above code contains `XFalse` instead of `XTrue`. > > 4. If we use the correct version of `returnProgress` as described just > before point 1 above, we get 15 times slower performance (the same or > very similar to the one when used altered `evalStateT` definition). We > could try to explain it: maybe Haskell was able to optimize code if it > discovered, there always were only `XFalse` values used and after the > change there are both `XTrue` and `XFalse`, so it really has to run the > `(|||)` operator. This way of thinking fails as fast as we check that > changing `XFalse` to `XTrue` **everywhere** in the code give us again bad > performance. > > 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we > get good performance, while replacing it with `return $! T b a'` give us > bad performance. It does not make any sense, because both `b` and `b'` > are strict and fully evaluated. Moreover, it is the only place in code > where they are used. > > 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' > ||| b) a'` does NOT change the performance (we are getting the good one). > > == Final notes > > We've been talking with some people - both in the company I'm working in > as well as on IRC and we do not see any reason why this code behaves in > this way and why it is so sensitive to the changes. In fact we started to > be worried a lot about how we can use Haskell for high-performance parts > at all if it is not obvious if a very simple changes do not affect > performance so much, like changing `evalStateT m = fmap fst . runStateT > m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times > slowdown. It makes the code both very fragile to any changes as well as > makes it unmaintainable. Tracking performance in a very small program > (like the attached one) is possible, while tracking it in bigger one, > taking in considerating the described problems, make it almost > impossible. I'm writing this because I'm worried about where these > problems originate from and I would really like to solve them / know why > they appear and be sure we can continue to use Haskell for our high- > performance demanding applications. New description: Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached.** The code is a pseudo-parser implementation. It consumes any char in a loop and fails on empty input in the end. Everything was compiled with following options (and many variations): `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. \\ == Helpers Let's define 2 helpers: {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} dotl :: (b -> c) -> (a -> b) -> a -> c dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} }}} So whenever we see `.` in code it is strict in all of its arguments. \\ == Strict StateT performance improvement Let's consider following code: {{{#!hs import qualified Control.Monad.State.Strict as S newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving (Applicative, Functor, Monad, MonadTrans) class MonadState s m | m -> s where get :: m s put :: s -> m () runStateT :: forall s m a. StateT s m a -> s -> m (a, s) evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT #-} evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT #-} instance Monad m => MonadState s (StateT s m) where get = StateT S.get ; {-# INLINE get #-} put = StateT . S.put ; {-# INLINE put #-} }}} There are few non-obvious things to note here: 1. This wrapper performs about **15 TIMES better** than `Control.Monad.State.Strict.StateT` (in the provided examples) and if we create a loop in pure code imitating a parser, this `StateT` gets completely optimized away, while the `mtl`'s version does not. 2. If we replace the following functions with lazy composition, we get the same, high performance: {{{#!hs runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} }}} 3. However, if we slightly change the `evalStateT`, we've got the bad performance, equals to the `mtl`'s `StateT` version (15 times slower): {{{#!hs evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} }}} It's a very strange result, especially that `evalStateT` is used only once in the code while running the tests. \\ == Strict Either & EitherT The code contains a very minimalistic implementation of `Either` and `EitherT` in order to make their definitions and utils strict. These definitions are copy-pasted and simplified (removed unused code) from: https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html \\ == Strict Bool and tuple Moreover we define strict Bool `or` operation and 2-element tuple with strict arguments: {{{#!hs data T a b = T !a !b deriving (Generic, Show, Functor) data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} }}} \\ == Parser implementation All the above declarations were simple helpers compiled with `-XStrict`, because available libraries do not provide them for us. This code is a "real" use case and shows the weird performance results. The parser implementation is simple: {{{#!hs newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b a <- ma T !b' a' <- fromFailParser $ f a return $! T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} instance MonadTrans (FailParser) where lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} }}} We use `undefined` for non-important functions. The parser is `EitherT` wrapper: Left happens when we failed parsing input, while Right otherwise. The `XBool` denotes if we made any progress (so after consuming a letter it is set to `XTrue`). There are some additional util functions, like `returnProgress` which behaves just like return, but also sets the `XBool` value to `XTrue`: {{{#!hs instance Monad m => MonadProgressParser (FailParser m) where returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE returnProgress #-} -- In correct code it should be XTrue as described below. }}} In the provided code, there is `XFalse` used instead of `XTrue` because of some interesting observations: 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| b') a'` above, so it does NOT affect the way the program logically executes it's body. 2. Both `b` and `b'` are strict and fully evaluated. 3. If both `b` and `b'` are `XFalse` (as in the provided code, they always are `XFalse`) we get a good performance. In order to test it, the above code contains `XFalse` instead of `XTrue`. 4. If we use the correct version of `returnProgress` as described just before point 1 above, we get 15 times slower performance (the same or very similar to the one when used altered `evalStateT` definition). We could try to explain it: maybe Haskell was able to optimize code if it discovered, there always were only `XFalse` values used and after the change there are both `XTrue` and `XFalse`, so it really has to run the `(|||)` operator. This way of thinking fails as fast as we check that changing `XFalse` to `XTrue` **everywhere** in the code give us again bad performance. 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we get good performance, while replacing it with `return $! T b a'` give us bad performance. It does not make any sense, because both `b` and `b'` are strict and fully evaluated. Moreover, it is the only place in code where they are used. 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' ||| b) a'` does NOT change the performance (we are getting the good one). == Final notes We've been talking with some people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. In fact we started to be worried a lot about how we can use Haskell for high-performance parts at all, if it is not obvious if a very simple change do not affect performance a lot. A good example is changing `evalStateT m = fmap fst . runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives 15 times slowdown. This situation makes the source code both very fragile to any changes as well as makes it unmaintainable. Tracking performance in a very small program (like the attached one) is possible, while tracking it in bigger one, taking in consideration the described problems, make it almost impossible. I'm writing this because I'm worried about where these problems originate from and I would really like to solve them / know why they appear, and be sure we can continue to use Haskell for our high- performance demanding applications. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 03:01:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 03:01:23 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build Message-ID: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building GHC HEAD using a `mk/build.mk` file with the following settings: {{{ BuildFlavour = prof GhcStage2HcOpts = -O0 $(GhcFAsm) -fprof-auto -DDEBUG }}} I find myself knee-deep in segfault town: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170726: http://www.haskell.org/ghc/ :? for help Segmentation fault (core dumped) }}} Welp. Here's what happens when I run it through `gdb`: {{{ $ gdb inplace/lib/bin/ghc-stage2 GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from inplace/lib/bin/ghc-stage2...done. (gdb) r -B"/u/rgscott/Software/ghc2/inplace/lib" --interactive Starting program: /home/rgscott/Software/ghc2/inplace/lib/bin/ghc-stage2 -B"/u/rgscott/Software/ghc2/inplace/lib" --interactive [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff635e700 (LWP 13161)] [New Thread 0x7ffff5b5d700 (LWP 13162)] [New Thread 0x7ffff535c700 (LWP 13163)] [New Thread 0x7ffff4b5b700 (LWP 13164)] GHCi, version 8.3.20170726: http://www.haskell.org/ghc/ :? for help Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff4b5b700 (LWP 13164)] 0x000000000514ecb3 in interpretBCO (cap=0x64b9fc0 ) at rts/Interpreter.c:743 743 if (get_itbl(UNTAG_CLOSURE(pap->fun))->type != BCO) { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 03:40:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 03:40:13 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build In-Reply-To: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> References: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> Message-ID: <065.787174f9b71fbf8ae32afbcddf3253f8@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) Comment: The offending commit is f9c6d53fe997f1c560cda6f346f4b201711df37c (Tag the FUN before making a PAP (#13767)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 05:29:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 05:29:57 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313985=3A_GHC_8=2E0_regression=3A_?= =?utf-8?q?=E2=80=98k=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <050.713def54cc371cef366e72c06648a03c@haskell.org> References: <050.713def54cc371cef366e72c06648a03c@haskell.org> Message-ID: <065.781615466a6d44596219a07aa905c0b7@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13738 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried looking at this, but I'm not nearly smart enough to sort out the chicken-and-egg problem that I uncovered. I //think// the solution would be to call [http://git.haskell.org/ghc.git/blob/d774b4e2de4f07d2432b67010305fede7aeefc78:/compiler/typecheck/TcHsType.hs#l2135 reportFloatingKvs] somewhere in the code that typechecks data family instances (e.g., [http://git.haskell.org/ghc.git/blob/d774b4e2de4f07d2432b67010305fede7aeefc78:/compiler/typecheck/TcInstDcls.hs#l622 tcDataFamInstDecl] seems like a good candidate). However, there's a serious problem with that: `reportFloatingKvs` needs tyvars to do its thing, but `tcDataFamInstDecl` starts out only having access to type patterns, not tyvars. To obtain tyvars, `tcDataFamInstDecl` calls `tcFamTyPats`, which in turn calls `kcDataDefn` to kind-check the type patterns. But therein lies the problem: `kcDataDefn` kind-checks each of the data constructors! By the time we do this, it's too late, since `k` wasn't rejected yet, so when we hit `k` when kind-checking a data constructor's existential type variables, GHC can't find it and throws an internal error. That is, `reportFloatingKvs` needs tyvars that `tcFamTyPats` produces, but `tcFamTyPats` can't produce the tyvars because it hits a kind variable which should have been rejected earlier by `reportFloatingKvs`. Ugh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 05:51:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 05:51:19 -0000 Subject: [GHC] #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error In-Reply-To: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> References: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> Message-ID: <065.5c01dde7a11d5adbf1fa976d1800debc@haskell.org> #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | 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): Phab:D3793 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 10:08:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 10:08:55 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.455bf15e0c2dc9e70f85cfa357d07ca1@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11565 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by choenerzs): Ok! I've HEAD prepared, and will start with simplified example code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:42:16 -0000 Subject: [GHC] #14037: Fix fusion for GHC's utility functions Message-ID: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a patchset I'm working on, I encountered a smallish "bytes allocated" regression in `perf/compiler/T5631`. After some sleuthing, I discovered that the regression is caused by using a `zipWith3M` where previously there was a `zipWithM`. Interestingly, it was not the zipped function that caused the problem, but the `zipWith3M` itself. Further sleuthing found that `zipWithM` is inlined into a combination of `sequenceA` and `zipWith`, both of which have been taught to work nicely with fusion. I thought of doing the same to GHC's `zipWith3M`, but I discovered that `base`'s `zipWith3` has no rules or inlining pragmas, suggesting that it does not fuse. I was quite surprised to find this, thinking that all functions as basic as `zipWith3` in `base` would play nicely with fusion. (Perhaps it does fuse -- I didn't actually check.) I then checked out GHC's `MonadUtils`, which defines a bunch of functions, some of which must be hammered on, and only one of which has any kind of performance- enhancing pragma. (The one is `zipWithAndUnzipM`, whose `INLINABLE` pragma was added only after much pain suffered by your dear author.) So: this ticket is a request to sweep through `MonadUtils` and `Util` and perhaps `ListSetOps`, looking for performance enhancements via fusion, tighter definitions, and such. Also, get `zipWith3` (and the other `zipWith`s) to fuse in `base`. I figure this is all some fairly low-hanging fruit for performance improvements in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.9649bc7e9dc660840d281b402831f2e6@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"8e15e3d370e9c253ae0dbb330e25b72cb00cdb76/ghc" 8e15e3d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e15e3d370e9c253ae0dbb330e25b72cb00cdb76" Improve error messages around kind mismatches. Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #12373: Type error but types match In-Reply-To: <043.bd1a92d82c4b4533b5d9ddee0a7fc4ab@haskell.org> References: <043.bd1a92d82c4b4533b5d9ddee0a7fc4ab@haskell.org> Message-ID: <058.f0eceba21f1df068560dde2c133a6fbd@haskell.org> #12373: Type error but types match -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | 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 Richard Eisenberg ): In [changeset:"8e15e3d370e9c253ae0dbb330e25b72cb00cdb76/ghc" 8e15e3d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e15e3d370e9c253ae0dbb330e25b72cb00cdb76" Improve error messages around kind mismatches. Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.bdf3102ad95bf119e74e3eb4277d5cb3@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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 Richard Eisenberg ): In [changeset:"8e15e3d370e9c253ae0dbb330e25b72cb00cdb76/ghc" 8e15e3d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e15e3d370e9c253ae0dbb330e25b72cb00cdb76" Improve error messages around kind mismatches. Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.ea2787ec1835ae0941d0c2c08cff06dd@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8e15e3d370e9c253ae0dbb330e25b72cb00cdb76/ghc" 8e15e3d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e15e3d370e9c253ae0dbb330e25b72cb00cdb76" Improve error messages around kind mismatches. Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.370ecf2494ed0b2246681b28c617bfcc@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c9667d321c94ff0f67b73aa7bd560c38873f7df5/ghc" c9667d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9667d321c94ff0f67b73aa7bd560c38873f7df5" Fix #11400, #11560 by documenting an infelicity. Really, the fix for both of these is #11307. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.65da53498341da74a296d9c281d83c59@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 11307 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c9667d321c94ff0f67b73aa7bd560c38873f7df5/ghc" c9667d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9667d321c94ff0f67b73aa7bd560c38873f7df5" Fix #11400, #11560 by documenting an infelicity. Really, the fix for both of these is #11307. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #14037: Fix fusion for GHC's utility functions In-Reply-To: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> References: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> Message-ID: <062.5ad4ec4559b4ffeee7084545e171c110@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"fb752133f45f01b27240d7cc6bce2063a015e51b/ghc" fb75213/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb752133f45f01b27240d7cc6bce2063a015e51b" Track visibility in TypeEqOrigin A type equality error can arise from a mismatch between *invisible* arguments just as easily as from visible arguments. But we should really prefer printing out errors from visible arguments over invisible ones. Suppose we have a mismatch between `Proxy Int` and `Proxy Maybe`. Would you rather get an error between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought so, too. There is a fair amount of plumbing with this one, but I think it's worth it. This commit introduces a performance regression in test perf/compiler/T5631. The cause of the regression is not the new visibility stuff, directly: it's due to a change from zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM is nicely optimized (it fuses away), but zipWith3M is not. There are other examples of functions that could be made faster, so I've posted a separate ticket, #14037, to track these improvements. For now, I've accepted the small (6.6%) regression. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.80f590e0c6b7f7d0e0cbc1d959fd8ec3@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: #13643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8e15e3d370e9c253ae0dbb330e25b72cb00cdb76/ghc" 8e15e3d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e15e3d370e9c253ae0dbb330e25b72cb00cdb76" Improve error messages around kind mismatches. Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.682a11046002fa2bc6c310aff1bf97f6@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11400 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c9667d321c94ff0f67b73aa7bd560c38873f7df5/ghc" c9667d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9667d321c94ff0f67b73aa7bd560c38873f7df5" Fix #11400, #11560 by documenting an infelicity. Really, the fix for both of these is #11307. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.9be362304494c8a90e676a05911498fe@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | TypeErrorMessages, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"9a54975665f23df8c8137da24028a5aec4c77fba/ghc" 9a54975/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9a54975665f23df8c8137da24028a5aec4c77fba" Test #11672 in typecheck/should_fail/T11672. I believe this was fixed with the fix for #11198. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.0f25af4be34b3b3af8e0435c5465a63d@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"9a54975665f23df8c8137da24028a5aec4c77fba/ghc" 9a54975/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9a54975665f23df8c8137da24028a5aec4c77fba" Test #11672 in typecheck/should_fail/T11672. I believe this was fixed with the fix for #11198. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #12176: Failure of bidirectional type inference at the kind level In-Reply-To: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> References: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> Message-ID: <062.ee616bfa87773ecb102deadfef36021f@haskell.org> #12176: Failure of bidirectional type inference at the kind level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"1696dbf4ad0fda4d7c5b4afe1911cab51d7dd0b0/ghc" 1696dbf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1696dbf4ad0fda4d7c5b4afe1911cab51d7dd0b0" Fix #12176 by being a bit more careful instantiating. Previously, looking up a TyCon that said "no" to mightBeUnsaturated would then instantiate all of its invisible binders. But this is wrong for vanilla type synonyms, whose RHS kind might legitimately start with invisible binders. So a little more care is taken now, only to instantiate those invisible binders that need to be (so that the TyCon isn't unsaturated). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:36 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.450ca7a715545a2a868fa9adc189cbd0@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Phab:D3754 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c2417b87ff59c92fbfa8eceeff2a0d6152b11a47/ghc" c2417b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2417b87ff59c92fbfa8eceeff2a0d6152b11a47" Fix #13819 by refactoring TypeEqOrigin.uo_thing The uo_thing field of TypeEqOrigin is used to track the "thing" (either term or type) that has the type (kind) stored in the TypeEqOrigin fields. Previously, this was sometimes a proper Core Type, which needed zonking and tidying. Now, it is only HsSyn: much simpler, and the error messages now use the user-written syntax. But this aspect of uo_thing didn't cause #13819; it was the sibling field uo_arity that did. uo_arity stored the number of arguments of uo_thing, useful when reporting something like "should have written 2 fewer arguments". We wouldn't want to say that if the thing didn't have two arguments. However, in practice, GHC was getting this wrong, and this message didn't seem all that helpful. Furthermore, the calculation of the number of arguments is what caused #13819 to fall over. This patch just removes uo_arity. In my opinion, the change to error messages is a nudge in the right direction. Test case: typecheck/should_fail/T13819 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #11995: Can't infer type In-Reply-To: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> References: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> Message-ID: <066.4fd642f04cc1060ad88ad10e3bda5204@haskell.org> #11995: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"ca471860494484210b6291dd96d1e0868da750e7/ghc" ca471860/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ca471860494484210b6291dd96d1e0868da750e7" Document that type holes kill polymorphic recursion This "fixes" #11995. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.496e6bd76e4b9334751e09abc0a3d3e9@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"4239238306e911803bf61fdda3ad356fd0b42e05/ghc" 4239238/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4239238306e911803bf61fdda3ad356fd0b42e05" Fix #12369 by being more flexible with data insts Previously, a data family's kind had to end in `Type`, and data instances had to list all the type patterns for the family. However, both of these restrictions were unnecessary: - A data family's kind can usefully end in a kind variable `k`. See examples on #12369. - A data instance need not list all patterns, much like how a GADT-style data declaration need not list all type parameters, when a kind signature is in place. This is useful, for example, here: data family Sing (a :: k) data instance Sing :: Bool -> Type where ... This patch also improved a few error messages, as some error plumbing had to be moved around. See new Note [Arity of data families] in FamInstEnv for more info. test case: indexed-types/should_compile/T12369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #11963: GHC introduces kind equality without TypeInType In-Reply-To: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> References: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> Message-ID: <060.327ae7c8cc972504729bc8fc79bb9d00@haskell.org> #11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"10d13b62c7ba8c44000a0d25afd66788de8040c4/ghc" 10d13b6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10d13b62c7ba8c44000a0d25afd66788de8040c4" Fix #11963 by checking for more mixed type/kinds This is a straightforward fix -- there were just some omitted checks. test case: typecheck/should_fail/T11963 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:49:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:49:37 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.36f1313dd7b9d9a24889444fa1752be2@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 Richard Eisenberg ): In [changeset:"791947db6db32ef7d4772a821a0823e558e3c05b/ghc" 791947db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="791947db6db32ef7d4772a821a0823e558e3c05b" Refactor tcInferApps. With the changes caused by the fix to #12369, it is now clearer how to rewrite tcInferApps and friends. This should change no behavior, but it does clean up a nasty corner of the type checker. This commit also removes some uses of substTyUnchecked. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:52:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:52:09 -0000 Subject: [GHC] #12373: Type error but types match In-Reply-To: <043.bd1a92d82c4b4533b5d9ddee0a7fc4ab@haskell.org> References: <043.bd1a92d82c4b4533b5d9ddee0a7fc4ab@haskell.org> Message-ID: <058.9aa8df0bce3c33b67b92f3f5eb022996@haskell.org> #12373: Type error but types match -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12373 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T12373 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:53:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:53:09 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.11c459cd2d11e8c454c592d75a3028b2@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13530 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T13530 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:54:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:54:06 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.6c40778f18615a8e271c1739d39c1780@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T12369 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => indexed-types/should_compile/T12369 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:55:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:55:56 -0000 Subject: [GHC] #11995: Can't infer type In-Reply-To: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> References: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> Message-ID: <066.db31585535f9df3ad1dc237c1c0bec82@haskell.org> #11995: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: May as well merge the documentation update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:55:20 -0000 Subject: [GHC] #11963: GHC introduces kind equality without TypeInType In-Reply-To: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> References: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> Message-ID: <060.e738f7c8019c60d2b6bb2e6e10a8fc1a@haskell.org> #11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: johnleo Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T11963 * status: new => merge * milestone: => 8.2.2 Comment: This seems easy enough to merge, but it's far from critical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:58:38 -0000 Subject: [GHC] #12176: Failure of bidirectional type inference at the kind level In-Reply-To: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> References: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> Message-ID: <062.4b18662da02c0a574f43d15fc003ca07@haskell.org> #12176: Failure of bidirectional type inference at the kind level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12176 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T12176 * status: new => merge Comment: Merge if convenient, but I don't think this one ruins anyone's day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 11:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 11:59:34 -0000 Subject: [GHC] #13819: TypeApplications-related GHC panic In-Reply-To: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> References: <051.cbfd374163652d5209657cd86d4948f0@haskell.org> Message-ID: <066.49819cd8a5a2de7691c37b0e3a5d9db6@haskell.org> #13819: TypeApplications-related GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: merge Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13819 Blocked By: | Blocking: Related Tickets: #13846, #13850 | Differential Rev(s): Phab:D3754 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T13819 * status: patch => merge Comment: This patch isn't tiny, but it seems worthwhile to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:01:10 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.677c4747f0adef9e5bedbf7be3fa31e4@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/{T8262,T8603,tcfail122} * status: new => merge * milestone: 8.4.1 => 8.2.2 Comment: I'm going to label this merge, as it would really be nice to get this into 8.2.2. But I don't really mean it, because it's a sizeable change. Judge for yourself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:01:58 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.a30ac435b3b6cc957f33522e03d2dd9d@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: fixed | TypeErrorMessages, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T11672 Blocked By: | Blocking: Related Tickets: #11198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T11672 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:04:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:04:28 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.a01f71bddb38665bd5bff5bad656a8d6@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 11307 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: May as well merge the documentation update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:04:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:04:53 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.79d131cf711d7de802e665f9e991e1a6@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:05:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:05:25 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.182e0b73211cfc2eea9bc6ad5577d2ab@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13610 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T13610 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 12:42:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 12:42:32 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.75c123c6daf0df79335e9378ce5ccc37@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 heisenbug): When implemented, one could test: `\case Right a → Just a` should be `seq b (unsafeCoerce b)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:29:54 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2314038=3A_TypeApplications_regression_in_G?= =?utf-8?q?HC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_inside_?= =?utf-8?q?the_constraints=3A_=28=29?= Message-ID: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This file: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Eliminator where import Data.Kind (Type) data family Sing (a :: k) data instance Sing (z :: [a]) where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x:xs) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ data FunArrow = (:->) -- ^ '(->)' | (:~>) -- ^ '(~>)' class FunType (arr :: FunArrow) where type Fun (k1 :: Type) arr (k2 :: Type) :: Type class FunType arr => AppType (arr :: FunArrow) where type App k1 arr k2 (f :: Fun k1 arr k2) (x :: k1) :: k2 type FunApp arr = (FunType arr, AppType arr) instance FunType (:->) where type Fun k1 (:->) k2 = k1 -> k2 instance AppType (:->) where type App k1 (:->) k2 (f :: k1 -> k2) x = f x instance FunType (:~>) where type Fun k1 (:~>) k2 = k1 ~> k2 instance AppType (:~>) where type App k1 (:~>) k2 (f :: k1 ~> k2) x = f @@ x infixr 0 -?> type (-?>) (k1 :: Type) (k2 :: Type) (arr :: FunArrow) = Fun k1 arr k2 elimList :: forall (a :: Type) (p :: [a] -> Type) (l :: [a]). Sing l -> p '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> p xs -> p (x:xs)) -> p l elimList = elimListPoly @(:->) elimListTyFun :: forall (a :: Type) (p :: [a] ~> Type) (l :: [a]). Sing l -> p @@ '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> p @@ xs -> p @@ (x:xs)) -> p @@ l elimListTyFun = elimListPoly @(:~>) @_ @p elimListPoly :: forall (arr :: FunArrow) (a :: Type) (p :: ([a] -?> Type) arr) (l :: [a]). FunApp arr => Sing l -> App [a] arr Type p '[] -> (forall (x :: a) (xs :: [a]). Sing x -> Sing xs -> App [a] arr Type p xs -> App [a] arr Type p (x:xs)) -> App [a] arr Type p l elimListPoly SNil pNil _ = pNil elimListPoly (SCons x (xs :: Sing xs)) pNil pCons = pCons x xs (elimListPoly @arr @a @p @xs xs pNil pCons) }}} Typechecks in GHC 8.2.1 without issue, but fails in GHC HEAD: {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Eliminator ( Bug.hs, interpreted ) Bug.hs:59:12: error: • Couldn't match type ‘p0’ with ‘p’ because type variables ‘a1’, ‘p’ would escape their scope These (rigid, skolem) type variables are bound by the type signature for: elimList :: forall a1 (p :: [a1] -> *) (l :: [a1]). Sing l -> p '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> p xs -> p (x : xs)) -> p l at Bug.hs:(54,1)-(58,15) Expected type: Sing l -> p '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> p xs -> p (x : xs)) -> p l Actual type: Sing l -> App [a1] (':->) * p0 '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> App [a1] (':->) * p0 xs -> App [a1] (':->) * p0 (x : xs)) -> App [a1] (':->) * p0 l • In the expression: elimListPoly @(:->) In an equation for ‘elimList’: elimList = elimListPoly @(:->) • Relevant bindings include elimList :: Sing l -> p '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> p xs -> p (x : xs)) -> p l (bound at Bug.hs:59:1) | 59 | elimList = elimListPoly @(:->) | ^^^^^^^^^^^^^^^^^^^ Bug.hs:59:12: error: • Couldn't match type ‘p0’ with ‘p’ ‘p0’ is untouchable inside the constraints: () bound by a type expected by the context: forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> App [a1] (':->) * p0 xs -> App [a1] (':->) * p0 (x : xs) at Bug.hs:59:12-30 ‘p’ is a rigid type variable bound by the type signature for: elimList :: forall a1 (p :: [a1] -> *) (l :: [a1]). Sing l -> p '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> p xs -> p (x : xs)) -> p l at Bug.hs:(54,1)-(58,15) Expected type: Sing x -> Sing xs -> App [a1] (':->) * p0 xs -> App [a1] (':->) * p0 (x : xs) Actual type: Sing x -> Sing xs -> p xs -> p (x : xs) • In the expression: elimListPoly @(:->) In an equation for ‘elimList’: elimList = elimListPoly @(:->) • Relevant bindings include elimList :: Sing l -> p '[] -> (forall (x :: a1) (xs :: [a1]). Sing x -> Sing xs -> p xs -> p (x : xs)) -> p l (bound at Bug.hs:59:1) | 59 | elimList = elimListPoly @(:->) | ^^^^^^^^^^^^^^^^^^^ }}} A workaround is to explicitly apply `p` with `TypeApplications` in line 59: {{{#!hs elimList = elimListPoly @(:->) @_ @p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:36:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:36:38 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.d357197aec2929c2aeba3442ede44d4c@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be fixed in GHC HEAD. I need to figure out which commit did the deed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:41:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:41:03 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.f5030f928104620a8c70153bfc6cc759@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Er, to be clear, the //original// program is fixed. I can't tell if the program in comment:2 panics anymore since it triggers #14038, and the program in comment:1 still panics, so at the very least I'll open a new ticket for the comment:1 program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:42:38 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.394f6ab9fb357e0acbf6774b442d83ba@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13877 Comment: If this bug is fixed, we should see if the program in https://ghc.haskell.org/trac/ghc/ticket/13877#comment:2 panics or not, since whether it panics or not is masked by the bug in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:44:03 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.182619297950ff0b994dea3302f4bf6f@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be fixed in GHC HEAD. I need to figure out which commit did the deed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 13:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 13:46:52 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.87c82a279a140cf5031fa1f9bf65a899@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism 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 RyanGlScott): This appears to be fixed in GHC HEAD. I need to figure out which commit did the deed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:10:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:10:20 -0000 Subject: [GHC] #14039: Add ability to install libraries bundled with ghc into separate prefixes Message-ID: <045.d5cc12f0c1ea91dc7120c0bcb6221795@haskell.org> #14039: Add ability to install libraries bundled with ghc into separate prefixes -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 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: -------------------------------------+------------------------------------- Currently, if I build an executable dynamically linked to 'base' and 'rts' with nix, I am forced to bring the ghc binary and, say, 'hoopl' along at runtime because these are all installed into the same prefix. Having options to indpendently specify output prefixes for each of the libraries would allow us to significantly decrease closure sizes. Ben Gamari suggests this may be doable in the new Hadrian build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:14:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:14:22 -0000 Subject: [GHC] #14039: Add ability to install libraries bundled with ghc into separate prefixes In-Reply-To: <045.d5cc12f0c1ea91dc7120c0bcb6221795@haskell.org> References: <045.d5cc12f0c1ea91dc7120c0bcb6221795@haskell.org> Message-ID: <060.cc5aeb255902cccf48d3c9391daaee1e@haskell.org> #14039: Add ability to install libraries bundled with ghc into separate prefixes -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: snowleopard (added) Comment: Andrey, this is a feature request for Hadrian's `make install`. It's not entirely clear yet how to make this happen but I thought that we should at least write it down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:20:11 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.d0e7f1b2d3418d63c826d4f3c51eae42@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, in a `-DDEBUG` compiler this falls over with {{{ Following filled tyvar a_a225[tau:2] = a_a220[sk:2] Unfilled tyvar a_a220[sk:2] flatten/appty (p0_a226[tau:2] |> T14038.D:R:Funk1:->k2[0] _N _N) '[] p0_a226[tau:2] '[] nominal nominal flatten } p0_a226[tau:2] '[] New coercion hole: a23h Emitting new coercion holeghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170726 for x86_64-unknown-linux): piResultTy Fun [a_a220[sk:2]] (':->) * '[] Call stack: ?callStack, called at compiler/utils/Util.hs:1394:50 in ghc:Util prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:949:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I think what is happening is that we start with `(p0_a226 |> co) '[]`, where `p0_a226 :: Fun [a_a220[sk:2]] (':->) *`, and `co` casts it to a function type. But then flattening throws away the cats, apparently, and we try to form `(mkAppTy p0_a226 '[])`, which is simply ill-kinded. I have (again) lost track of what is supposed to happen here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:21:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:21:07 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm In-Reply-To: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> References: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> Message-ID: <061.a3165aa246d4c5d3c6021fb56b9569f9@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3787 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3780 => Phab:D3787 Comment: Actually, Phab:D3780 won't quite work; Phab:D3787 is a bit better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:27:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:27:28 -0000 Subject: [GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo In-Reply-To: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> References: <042.34302b4b71123d8bdacd7debc1ac7aea@haskell.org> Message-ID: <057.e00b3bba148562c59d9cbc43ed04518a@haskell.org> #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => simonmar * priority: normal => highest * milestone: => 8.2.2 Comment: An infinite loop in the compiler is bad! Something to do with renaming I think. Simon M: would you like to look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:30:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:30:40 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.057ef3f100aca75593435048edf040e0@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 simonpj): It doesn't look like a hornets nest to me. In the example you give, the occurrence of `con2Tag` is simply ambiguous because there are two bindings, both with the same unqualified name. I think the `RdrName`s generated by `newName` are `Exact`, right? Not `Unqual`. Maybe the renamer should not complain about collisions between `Exact` top-level names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 14:35:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 14:35:34 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.ba086ece5ffd464322e43f479088f6f3@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): Replying to [comment:10 simonpj]: > I think the `RdrName`s generated by `newName` are `Exact`, right? Not `Unqual`. Maybe the renamer should not complain about collisions between `Exact` top-level names. No, they are unqualified. See https://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05b:/compiler/typecheck/TcSplice.hs#l835 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:17:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:17:13 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.8d473ea0d1c82bff892e65cf4e8cf709@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13819 Comment: This was fixed in c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 (Fix #13819 by refactoring TypeEqOrigin.uo_thing). TODO: Add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:17:33 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.1b5aadfe377a4d2b1559adf66bce6aee@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13819 Comment: These were fixed in c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 (Fix #13819 by refactoring TypeEqOrigin.uo_thing). TODO: Add regression tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:29:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:29:53 -0000 Subject: [GHC] #14039: Add ability to install libraries bundled with ghc into separate prefixes In-Reply-To: <045.d5cc12f0c1ea91dc7120c0bcb6221795@haskell.org> References: <045.d5cc12f0c1ea91dc7120c0bcb6221795@haskell.org> Message-ID: <060.8337cc1dfb38a520298e1b90a2d2cab0@haskell.org> #14039: Add ability to install libraries bundled with ghc into separate prefixes -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 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 snowleopard): I think it shouldn't be difficult to install different libraries into different locations in Hadrian. But most likely this feature request will have to wait until Hadrian is merged into GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:36:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:36:14 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.bbdce1b3cbe3166b52b7a3a00eb4fee9@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 (`Improve error messages around kind mismatches.`) caused this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:38:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:38:39 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.0b0e973f2cde31634b956e1c84dfd34e@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Commit 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 (`Improve error messages around kind mismatches.`) fixed the original program. TODO: Add regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:47:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:47:20 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] Message-ID: <050.973ad933fee1878607a6ab042ec05467@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, | PartialTypeSignatures | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13877 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #13877.) The following program gives a somewhat decent error message in GHC 8.0.1: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data family Sing (a :: k) data WeirdList :: Type -> Type where WeirdNil :: WeirdList a WeirdCons :: a -> WeirdList (WeirdList a) -> WeirdList a data instance Sing (z :: WeirdList a) where SWeirdNil :: Sing WeirdNil SWeirdCons :: Sing w -> Sing wws -> Sing (WeirdCons w wws) elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl elimWeirdList SWeirdNil pWeirdNil _ = pWeirdNil elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} {{{ $ /opt/ghc/8.0.1/bin/ghci Foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:34:8: error: • Cannot apply expression of type ‘Sing wl -> (forall y. p x0 t3 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t2 xs -> p z t1 ('WeirdCons x xs)) -> p a t0 wl’ to a visible type argument ‘WeirdList z’ • In the sixth argument of ‘pWeirdCons’, namely ‘(elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons)’ In the expression: pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) In an equation for ‘elimWeirdList’: elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} But in GHC 8.0.2, 8.2.1, and HEAD, it panics to varying degrees: {{{ $ /opt/ghc/8.0.2/bin/ghci Foo.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘t0’ Where: ‘t0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl • Relevant bindings include elimWeirdList :: Sing wl -> (forall y. p x0 t0 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t1 xs -> p z t2 ('WeirdCons x xs)) -> p a t3 wl (bound at Foo.hs:29:1) Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: z_a13X[sk] }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:21:18: error: • The kind of variable ‘wl1’, namely ‘WeirdList a1’, depends on variable ‘a1’ from an inner scope Perhaps bind ‘wl1’ sometime after binding ‘a1’ • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 21 | elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘w0’ Where: ‘w0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 24 | -> (forall (y :: Type). p _ WeirdNil) | ^ Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): No skolem info: z_a1sY[sk:2] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors }}} (The error messages from HEAD, at commit 791947db6db32ef7d4772a821a0823e558e3c05b, are the same as in GHC 8.2.1.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:48:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:48:02 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.c3735113969206c46edc147b50f0fdfe@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910, #14040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13910 => #13910, #14040 Comment: I've opened a separate ticket #14040 for the program in comment:1, since it wasn't fixed by 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:49:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:49:44 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 Message-ID: <053.b99b243583300981f24cb199e196b0b4@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: | Owner: (none) romanzolotarev | Type: bug | Status: new Priority: normal | Milestone: Research needed Component: None | Version: 8.2.1 Keywords: | Operating System: OpenBSD Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have tried to install ghc-8.2.1 directly and via stack. Getting the same error: {{{ ld.so: ghc-cabal: can't load library 'libgmp.so.9.0' }}} Seems like ghc requires 'libgmp.so.9.0', while OpenBSD 6.1 has 'libgmp.so.10.0' by default. {{{ # find / -name libgmp.so* /usr/local/lib/libgmp.so.10.0 }}} ---- Here are full logs: {{{ OpenBSD 6.1 (GENERIC) #19: Sat Apr 1 13:42:46 MDT 2017 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. # ./.cabal/bin/stack setup 8.2.1 Preparing to install GHC to an isolated location. This will not interfere with any system-level installation. Already downloaded. Running /usr/local/bin/gmake install in directory /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ exited with ExitFailure 2 /usr/local/bin/gmake --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES "rm" -f utils/ghc-pkg/dist-install/build/Version.hs echo "module Version where" >> utils/ghc-pkg/dist- install/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist- install/build/Version.hs echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist- install/build/Version.hs echo "targetOS = \"openbsd\"" >> utils/ghc-pkg/dist- install/build/Version.hs echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist- install/build/Version.hs "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist/build/Version.hs echo "targetOS = \"openbsd\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist/build/Version.hs /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'exeprog="hp2ps"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" cat utils/hp2ps/hp2ps.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" echo 'exec "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" --interactive "$@"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci" ln -s ghci-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/." && /usr/bin/install -c -m 644 includes/./*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/./" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg/" && true /usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist- derivedconstants/header/DerivedConstants.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'exeprog="haddock"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" cat utils/haddock/haddock.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html /haddock-util.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/haskell_icon.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/xhaddock.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/hslogo-16.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/ocean.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/synopsis.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/solarized.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/highlight.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/latex/haddock.sty "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock" ln -s haddock-ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'exeprog="hsc2hs"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'HSC2HS_EXTRA="--cflag=-std=gnu99 --cflag=-fno-stack-protector --lflag=-Wl,-z,wxneeded"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" cat utils/hsc2hs/hsc2hs.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'exeprog="ghc-pkg"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" cat utils/ghc-pkg/ghc-pkg.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg" ln -s ghc-pkg-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin /ghc-pkg" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'exeprog="hpc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" cat utils/hpc/hpc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'exeprog="runghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'ghcprog="ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" cat utils/runghc/runghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell" ln -s runghc "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc" ln -s runghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'exeprog="ghc-stage2"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'executablename="$exedir/ghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" cat ghc/ghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc" ln -s ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1" /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1" # driver/ghc-usage.txt driver/ghci-usage.txt includes/dist- derivedconstants/header/platformConstants settings = libraries to install # "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" = directory to install to # # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist- derivedconstants/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; esac; done gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' -DINCLUDE_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include"' -DFFI_INCLUDE_DIR=/usr/local/include -DFFI_LIB_DIR=/usr/local/lib '-DFFI_LIB=' -x c -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw grep -v '^#pragma GCC' rts/dist/package.conf.install.raw | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/dist/package.conf.install /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin" for i in utils/unlit/dist/build/tmp/unlit utils/hp2ps/dist/build/tmp/hp2ps utils/hp2ps/dist/build/tmp/hp2ps utils/haddock/dist/build/tmp/haddock utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist- install/build/tmp/hsc2hs utils/hsc2hs/dist-install/build/tmp/hsc2hs utils /ghc-pkg/dist-install/build/tmp/ghc-pkg utils/ghc-pkg/dist- install/build/tmp/ghc-pkg utils/hpc/dist-install/build/tmp/hpc utils/hpc /dist-install/build/tmp/hpc utils/runghc/dist-install/build/tmp/runghc utils/runghc/dist-install/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2 ghc/stage2/build/tmp/ghc-stage2 iserv/stage2/build/tmp/ghc-iserv iserv/stage2_p/build/tmp/ghc-iserv-prof iserv/stage2_dyn/build/tmp/ghc- iserv-dyn; do \ /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"; \ done "mv" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin /ghc-stage2" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" "rm" -rf "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" # rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build /libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug- ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build /libHSrts_thr_l-ghc8.2.1.so = libraries to install # "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" = directory to install to # # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug- ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build /libHSrts_thr_l-ghc8.2.1.so; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; esac; done "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/doc/ghc-8.2.1/html/libraries' 'v p dyn' ld.so: ghc-cabal: can't load library 'libgmp.so.9.0' Killed gmake[1]: *** [ghc.mk:991: install_packages] Error 137 gmake: *** [Makefile:51: install] Error 2 Error: Error encountered while installing GHC with gmake install run in /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ The following directories may now contain files, but won't be used by stack: - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1/ Installing GHC ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 15:56:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 15:56:35 -0000 Subject: [GHC] #14031: Linker paths carry substantial N*M overhead when many libaries are used In-Reply-To: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> References: <042.ce0993e2e172f32ad763c1e5e7a5881f@haskell.org> Message-ID: <057.bff0011f1226be53b37eb2578ff60594@haskell.org> #14031: Linker paths carry substantial N*M overhead when many libaries are used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Result on the binutils mailing list: > It is mostly just lookup convenience. If you replace the -l option with the full path of the library that is found, the result will be almost identical. The only differences I know of are error messages and the soname that will be used for a shared library with no DT_SONAME dynamic tag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:01:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:01:25 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.4019e452a940f1b43a279533f7585884@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): By the way ghc-8.0.2 works just fine on the same OpenBSD 6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:07:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:07:32 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.0b88d2f17e9e324141afbbaec0dff605@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910, #14040 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3794 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:07:46 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.9a6093d2e2827a49bdf881c8db8a08cb@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3794 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:07:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:07:59 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.eff9747e388ffc193d0f27d7ca8e03d4@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3794 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:21:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:21:34 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.eb7e056ddb798141b664b1c1eb38277b@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13780 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm confused then on what this ticket is about. Is the plan to keep this feature and fix the bugs reported in the original comment? FWIW, I noticed that even after commit c2417b87ff59c92fbfa8eceeff2a0d6152b11a47, which fixed several ugly pretty- printer bugs that caused things like `'GHC.Types.Eq#` to be printed, a similar pretty-printer bug in this ticket is still //not// fixed on GHC HEAD. For instance, this program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind import GHC.TypeLits hiding (type (*)) type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" instance Show (T 42) where }}} Still spits out `'GHC.Types.Eq#`: {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:21:10: error: • Illegal type synonym family application in instance: T ('Data.Type.Equality.C:~ ('GHC.Types.Eq# <>)) 42 • In the instance declaration for ‘Show (T 42)’ | 21 | instance Show (T 42) where | ^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:24:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:24:27 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.b7b2e7b5b39cc86ddc093121db501261@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T12369 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Could this work for `Constraint`s? GHC already accepts (maybe something to do with #11715) {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType -XTypeFamilies Prelude> import Data.Kind Prelude Data.Kind> data family COMPOSE k1 k2 k3 :: (k1 -> Type) -> (k2 -> k1) -> (k2 -> Constraint) Prelude Data.Kind> }}} but it cannot be used afaik, also fails with a return kind of `TYPE IntRep`. {{{ Prelude Data.Kind GHC.Prim GHC.Exts> data family COMPOSE k1 k2 k3 :: (k1 -> Type) -> (k2 -> k1) -> (k2 -> TYPE IntRep) :8:1: error: • Kind signature on data type declaration has non-* return kind (k1 -> *) -> (k2 -> k1) -> k2 -> TYPE 'IntRep • In the data family declaration for ‘COMPOSE’ }}} It would be interesting to combine {{{#!hs data Compose :: (k' -> Type) -> (k -> k') -> (k -> Type) where Compose :: f (g a) -> Compose f g a data Compose2 :: (k' -> (kk -> Type)) -> (k -> k') -> (k -> (kk -> Type)) where Compose2 :: f (g a) b -> Compose2 f g a b -- ComposeC :: (k' -> Constraint) -> (k -> k') -> (k -> Constraint) class f (g a) => ComposeC f g a instance f (g a) => ComposeC f g a -- ComposeC2 :: (k' -> (kk -> Constraint)) -> (k -> k') -> (k -> (kk -> Constraint)) class f (g a) b => ComposeC2 f g a b instance f (g a) b => ComposeC2 f g a b }}} as instances of a 'data' family indexed by `Type`, `kk -> Type`, `Constraint`, `kk -> Constraint` but I'm not sure if it's meaningful {{{#!hs data family Compose (k'' :: Type) :: (k' -> k'') -> (k -> k') -> (k -> k'') data instance Compose Type :: (k' -> Type) -> (k -> k') -> (k -> Type) where Compose :: f (g a) -> Compose Type f g a -- Hijacking DatatypeContexts syntax data instance f (g a) => Compose Constraint f g a data instance f (g a) b => Compose (kk -> Constraint) f g a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 16:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 16:43:34 -0000 Subject: [GHC] #14042: Data type with type family in return kind spuriously rejected Message-ID: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> #14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 17:31:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 17:31:46 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.e6d01ce5f688b7a31d75a7852be91c53@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds like we will need separate bindists for OpenBSD 6.0 and 6.1. Arg. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:23:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:23:22 -0000 Subject: [GHC] #14043: GHC.Stack.callStack throws exception Message-ID: <046.04c19b3f92ab14302022d82213714264@haskell.org> #14043: GHC.Stack.callStack throws exception -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.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: -------------------------------------+------------------------------------- This program, {{{#!hs import GHC.Stack main :: IO () main = putStrLn (prettyCallStack $ id (\_ -> callStack) ()) }}} terminates with, {{{ Hi: popCallStack: empty stack }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:23:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:23:56 -0000 Subject: [GHC] #14043: GHC.Stack.callStack throws exception In-Reply-To: <046.04c19b3f92ab14302022d82213714264@haskell.org> References: <046.04c19b3f92ab14302022d82213714264@haskell.org> Message-ID: <061.f3d925dcd6f46189609e30f82ddb12f0@haskell.org> #14043: GHC.Stack.callStack throws exception -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): The problem appears to be that `callStack` is defined directly in terms of `popCallStack`, which fails on an empty stack. Presumably we should just return an empty stack in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:26:47 -0000 Subject: [GHC] #14043: GHC.Stack.callStack throws exception In-Reply-To: <046.04c19b3f92ab14302022d82213714264@haskell.org> References: <046.04c19b3f92ab14302022d82213714264@haskell.org> Message-ID: <061.ca66cc33da6910be4262c19e9814a326@haskell.org> #14043: GHC.Stack.callStack throws exception -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3795 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3795 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:29:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:29:36 -0000 Subject: [GHC] #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 Message-ID: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 -------------------------------------+------------------------------------- Reporter: | Owner: (none) romanzolotarev | Type: bug | Status: new Priority: normal | Milestone: Research needed Component: None | Version: 8.2.1 Keywords: | Operating System: OpenBSD Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have tried to install ghc-8.2.1 directly and via stack. Getting the same error: {{{ ghc-cabal: can't load library 'libc.so.89.3' }}} ghc requires 'libc.so.89.3', while OpenBSD 6.0 has 'libc.so.88.0' by default. {{{ # find / -name libc.so* /usr/lib/libc.so.88.0 /usr/lib/libc.so.88.0.a }}} ---- Full log {{{ # /root/.cabal/bin/stack setup Preparing to install GHC to an isolated location. This will not interfere with any system-level installation. Already downloaded. Running /usr/local/bin/gmake install in directory /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ exited with ExitFailure 2 /usr/local/bin/gmake --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES "rm" -f utils/ghc-pkg/dist-install/build/Version.hs echo "module Version where" >> utils/ghc-pkg/dist- install/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/dist- install/build/Version.hs echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist- install/build/Version.hs echo "targetOS = \"openbsd\"" >> utils/ghc-pkg/dist- install/build/Version.hs echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist- install/build/Version.hs "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"8.2.1\"" >> utils/ghc-pkg/dist/build/Version.hs echo "targetOS = \"openbsd\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/dist/build/Version.hs /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'exeprog="hp2ps"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" cat utils/hp2ps/hp2ps.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hp2ps" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" echo 'exec "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" --interactive "$@"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci" ln -s ghci-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghci" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/." && /usr/bin/install -c -m 644 includes/./*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/./" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/stg/" && true /usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist- derivedconstants/header/DerivedConstants.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'exeprog="haddock"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" cat utils/haddock/haddock.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock-ghc-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html /haddock-util.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/haskell_icon.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/Classic.theme/xhaddock.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Classic.theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/hslogo-16.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/minus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/ocean.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/plus.gif "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock-api/resources/html/Ocean .std-theme/synopsis.png "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/Ocean .std-theme/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/solarized.css "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/html/highlight.js "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/html/" /usr/bin/install -c -m 644 utils/haddock/haddock- api/resources/latex/haddock.sty "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/latex/" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock" ln -s haddock-ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/haddock" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'exeprog="hsc2hs"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" echo 'HSC2HS_EXTRA="--cflag=-std=gnu99 --cflag=-fno-stack-protector --lflag=-Wl,-z,wxneeded"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" cat utils/hsc2hs/hsc2hs.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hsc2hs" /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'exeprog="ghc-pkg"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" cat utils/ghc-pkg/ghc-pkg.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg-8.2.1" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-pkg" ln -s ghc-pkg-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin /ghc-pkg" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'exeprog="hpc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" cat utils/hpc/hpc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/hpc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'exeprog="runghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" echo 'ghcprog="ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" cat utils/runghc/runghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell" ln -s runghc "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runhaskell" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc" ln -s runghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/runghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" create () { touch "$1" && chmod 755 "$1" ; } && create "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo '#!/bin/sh' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'exedir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'exeprog="ghc-stage2"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'executablename="$exedir/$exeprog"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'datadir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'bindir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'topdir="/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" echo 'executablename="$exedir/ghc"' >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" cat ghc/ghc.wrapper >> "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" chmod +x "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc-8.2.1" "rm" -f "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc" ln -s ghc-8.2.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/bin/ghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1" /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/man/man1" # driver/ghc-usage.txt driver/ghci-usage.txt includes/dist- derivedconstants/header/platformConstants settings = libraries to install # "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" = directory to install to # # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist- derivedconstants/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"; esac; done gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1"' -DINCLUDE_DIR='"/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/include"' -DFFI_INCLUDE_DIR=/usr/local/include -DFFI_LIB_DIR=/usr/local/lib '-DFFI_LIB=' -x c -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw grep -v '^#pragma GCC' rts/dist/package.conf.install.raw | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/dist/package.conf.install /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin" for i in utils/unlit/dist/build/tmp/unlit utils/hp2ps/dist/build/tmp/hp2ps utils/hp2ps/dist/build/tmp/hp2ps utils/haddock/dist/build/tmp/haddock utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist- install/build/tmp/hsc2hs utils/hsc2hs/dist-install/build/tmp/hsc2hs utils /ghc-pkg/dist-install/build/tmp/ghc-pkg utils/ghc-pkg/dist- install/build/tmp/ghc-pkg utils/hpc/dist-install/build/tmp/hpc utils/hpc /dist-install/build/tmp/hpc utils/runghc/dist-install/build/tmp/runghc utils/runghc/dist-install/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2 ghc/stage2/build/tmp/ghc-stage2 iserv/stage2/build/tmp/ghc-iserv iserv/stage2_p/build/tmp/ghc-iserv-prof iserv/stage2_dyn/build/tmp/ghc- iserv-dyn; do \ /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin"; \ done "mv" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin /ghc-stage2" "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/bin/ghc" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1" "rm" -rf "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/package.conf.d" /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" # rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build /libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug- ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build /libHSrts_thr_l-ghc8.2.1.so = libraries to install # "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" = directory to install to # # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. /usr/bin/install -c -m 755 -d "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.2.1.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.2.1.so rts/dist/build/libHSrts_thr-ghc8.2.1.so rts/dist/build/libHSrts_thr_debug- ghc8.2.1.so rts/dist/build/libHSrts_l-ghc8.2.1.so rts/dist/build /libHSrts_thr_l-ghc8.2.1.so; do case $i in *.a) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; true "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ; strip "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts";; *) /usr/bin/install -c -m 644 $i "/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1/rts"; esac; done "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/lib/ghc-8.2.1' '/root/.stack/programs/x86_64-openbsd/ghc-8.2.1/share/doc/ghc-8.2.1/html/libraries' 'v p dyn' ghc-cabal: can't load library 'libc.so.89.3' gmake[1]: *** [ghc.mk:991: install_packages] Error 4 gmake: *** [Makefile:51: install] Error 2 Error: Error encountered while installing GHC with gmake install run in /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ghc-8.2.1/ The following directories may now contain files, but won't be used by stack: - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1.temp/ - /root/.stack/programs/x86_64-openbsd/ghc-8.2.1/ Installing GHC ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:33:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:33:51 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.b7a44787ce279baf3487acdb3f9a1ceb@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): Created another ticket for ghc-8.2.1 and OpenBSD 6.0: https://ghc.haskell.org/trac/ghc/ticket/14044#ticket Similar issue, but different library. According to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/OpenBSD it should work on {{{OpenBSD Current as of 2017-04-05}}}. Maybe it was tested on OpenBSD snapshots on April 5th. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 18:50:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 18:50:12 -0000 Subject: [GHC] #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 In-Reply-To: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> References: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> Message-ID: <068.d4ece2d507e32f92d41f768c3aa751a4@haskell.org> #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): Linking to the similar ticket https://ghc.haskell.org/trac/ghc/ticket/14041#comment:3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 19:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 19:02:36 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary Message-ID: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #12369.) The documentation for data families currently [http://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05b:/docs/users_guide/8.4.1-notes.rst#l24 claims]: {{{ - Data families have been generalised a bit: a data family declaration can now end with a kind variable ``k`` instead of ``Type``. Additionally, data/newtype instance no longer need to list all the patterns of the family if they don't wish to; this is quite like how regular datatypes with a kind signature can omit some type variables. }}} Moreover, the commit which added this (4239238306e911803bf61fdda3ad356fd0b42e05) cites this particular example: {{{#!hs data family Sing (a :: k) data instance Sing :: Bool -> Type where ... }}} However, in practice, this does //not// typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind data family Sing (a :: k) data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:8:1: error: • Number of parameters must match family declaration; expected 0 • In the data instance declaration for ‘Sing’ | 8 | data instance Sing :: Bool -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 19:04:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 19:04:01 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.6938cbf647abffd658a0c190114837fa@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T12369 Blocked By: | Blocking: Related Tickets: #14045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14045 Comment: By the way, the commit message for 4239238306e911803bf61fdda3ad356fd0b42e05 claims: {{{ - A data instance need not list all patterns, much like how a GADT-style data declaration need not list all type parameters, when a kind signature is in place. This is useful, for example, here: data family Sing (a :: k) data instance Sing :: Bool -> Type where ... }}} I just tried this recently, and that example doesn't actually work. To avoid cluttering this ticket further, I've spun this off into #14045. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 19:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 19:09:47 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.59b10903299a5f7951a011ed6c83b902@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:18:28 -0000 Subject: [GHC] #13940: Reduce duplicate implementations of argument handling on Windows In-Reply-To: <047.8342ee8748562facc1285d21ddca3123@haskell.org> References: <047.8342ee8748562facc1285d21ddca3123@haskell.org> Message-ID: <062.d52e30e9a12f91688ea330037d566851@haskell.org> #13940: Reduce duplicate implementations of argument handling on Windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Resolution: | Keywords: unicode | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12870 | Differential Rev(s): Phab:D3739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"7af0b906116e13fbd90f43f2f6c6b826df2dca77/ghc" 7af0b906/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7af0b906116e13fbd90f43f2f6c6b826df2dca77" Initialize hs_init with UTF8 encoded arguments on Windows. Summary: Get utf8 encoded arguments before we call hs_init and use them instead of ignoring hs_init arguments. This reduces differing behaviour of the RTS between windows and linux and simplifies the code involved. A few testcases were changed to expect the same result on windows as on linux after the changes. This fixes #13940. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #13940 Differential Revision: https://phabricator.haskell.org/D3739 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:21:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:21:56 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.6cdad25180f6378013a0069aa0abad61@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Similarly, associated data family instances of this form are also rejected: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind class C (a :: k) where data Sing (a :: k) instance C (z :: Bool) where data Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:12:3: error: • Number of parameters must match family declaration; expected 0 • In the data instance declaration for ‘Sing’ In the instance declaration for ‘C (z :: Bool)’ | 12 | data Sing :: Bool -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} I'm not sure if such a thing would be permissible, since GHC imposes some [http://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05b:/docs/users_guide/glasgow_exts.rst#l7245 additional restrictions] on the type patterns of associated family instances. If it's not permissible, we should give a better error message here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:28:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:28:14 -0000 Subject: [GHC] #11958: Improved testing of cross-compiler In-Reply-To: <044.199977cda1889326e5e53eb484e40895@haskell.org> References: <044.199977cda1889326e5e53eb484e40895@haskell.org> Message-ID: <059.0ba3831f858ca5ddfd2c852b9518aeb3@haskell.org> #11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Test Suite | Version: 7.10.3 Resolution: | Keywords: cross-compile 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 bgamari): This is one goal of the new Jenkins CI infrastructure, see #13716. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:28:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:28:39 -0000 Subject: [GHC] #11958: Improved testing of cross-compiler In-Reply-To: <044.199977cda1889326e5e53eb484e40895@haskell.org> References: <044.199977cda1889326e5e53eb484e40895@haskell.org> Message-ID: <059.b680a5a783cb9320394a9339ffa56b74@haskell.org> #11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Test Suite | Version: 7.10.3 Resolution: | Keywords: cross-compile Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13716 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13716 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:28:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:28:43 -0000 Subject: [GHC] #13940: Reduce duplicate implementations of argument handling on Windows In-Reply-To: <047.8342ee8748562facc1285d21ddca3123@haskell.org> References: <047.8342ee8748562facc1285d21ddca3123@haskell.org> Message-ID: <062.7b5a83d7a07bb61a629b372f82c3ca01@haskell.org> #13940: Reduce duplicate implementations of argument handling on Windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: low | Milestone: Component: Runtime System | Version: Resolution: fixed | Keywords: unicode | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12870 | Differential Rev(s): Phab:D3739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:41:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:41:03 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.e084ff75916ee76aa94b8463dac67ae8@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! I was recently testing performance of a critical code in a product we > are shipping and I'm getting really weird results. > > **The code is compiled with `-XStrict` enabled globally. The full source > code for this ticket is attached.** > The code is a pseudo-parser implementation. It consumes any char in a > loop and fails on empty input in the end. > > Everything was compiled with following options (and many variations): > `"-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 > -funfolding-use-threshold=10000 -fexpose-all-unfoldings -fsimpl-tick- > factor=1000 -flate-dmd-anal -fspecialise-aggressively"`. > > \\ > > == Helpers > > Let's define 2 helpers: > {{{#!hs > (.) :: (b -> c) -> (a -> b) -> a -> c > (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} > > dotl :: (b -> c) -> (a -> b) -> a -> c > dotl ~f ~g = \ ~x -> f (g x) ; {-# INLINE dotl #-} > }}} > > So whenever we see `.` in code it is strict in all of its arguments. > > \\ > > == Strict StateT performance improvement > > Let's consider following code: > {{{#!hs > import qualified Control.Monad.State.Strict as S > > newtype StateT s m a = StateT { fromStateT :: S.StateT s m a } deriving > (Applicative, Functor, Monad, MonadTrans) > > class MonadState s m | m -> s where > get :: m s > put :: s -> m () > > runStateT :: forall s m a. StateT s m a -> s -> m (a, s) > evalStateT :: forall s m a. Functor m => StateT s m a -> s -> m a > runStateT m s = S.runStateT (fromStateT m) s ; {-# INLINE runStateT > #-} > evalStateT m = fmap fst . runStateT m ; {-# INLINE evalStateT > #-} > > instance Monad m => MonadState s (StateT s m) where > get = StateT S.get ; {-# INLINE get #-} > put = StateT . S.put ; {-# INLINE put #-} > }}} > > There are few non-obvious things to note here: > 1. This wrapper performs about **15 TIMES better** than > `Control.Monad.State.Strict.StateT` (in the provided examples) and if we > create a loop in pure code imitating a parser, this `StateT` gets > completely optimized away, while the `mtl`'s version does not. > > 2. If we replace the following functions with lazy composition, we get > the same, high performance: > {{{#!hs > runStateT = S.runStateT `dotl` fromStateT ; {-# INLINE runStateT #-} > evalStateT m = fmap fst `dotl` runStateT m ; {-# INLINE evalStateT #-} > }}} > > 3. However, if we slightly change the `evalStateT`, we've got the bad > performance, equals to the `mtl`'s `StateT` version (15 times slower): > {{{#!hs > evalStateT m a = fmap fst $ runStateT m a ; {-# INLINE evalStateT #-} > }}} > > It's a very strange result, especially that `evalStateT` is used only > once in the code while running the tests. > > \\ > > == Strict Either & EitherT > > The code contains a very minimalistic implementation of `Either` and > `EitherT` in order to make their definitions and utils strict. These > definitions are copy-pasted and simplified (removed unused code) from: > https://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Either.html > https://hackage.haskell.org/package/either-4.4.1.1/docs/src/Control.Monad.Trans.Either.html > > \\ > > == Strict Bool and tuple > > Moreover we define strict Bool `or` operation and 2-element tuple with > strict arguments: > > {{{#!hs > data T a b = T !a !b deriving (Generic, Show, Functor) > > data XBool = XTrue | XFalse deriving (Show, Generic) > > (|||) :: XBool -> XBool -> XBool > (|||) !a !b = case a of > XTrue -> a > XFalse -> b > {-# INLINE (|||) #-} > }}} > > \\ > > == Parser implementation > > All the above declarations were simple helpers compiled with `-XStrict`, > because available libraries do not provide them for us. This code is a > "real" use case and shows the weird performance results. > > The parser implementation is simple: > {{{#!hs > newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T > XBool a) } deriving (Functor) > > instance Monad m => Applicative (FailParser m) where > pure = undefined > (<*>) = undefined > > instance Monad m => Monad (FailParser m) where > return a = FailParser $ pure $ (T XFalse a) ; {-# INLINE return #-} > FailParser ma >>= f = FailParser $ do > T !b a <- ma > T !b' a' <- fromFailParser $ f a > return $! T (b ||| b') a' > {-# INLINE (>>=) #-} > _ >> _ = undefined ; {-# INLINE (>>) #-} > > instance MonadTrans (FailParser) where > lift m = FailParser $! lift $ fmap (T XFalse) m ; {-# INLINE lift #-} > }}} > > We use `undefined` for non-important functions. The parser is `EitherT` > wrapper: Left happens when we failed parsing input, while Right > otherwise. The `XBool` denotes if we made any progress (so after > consuming a letter it is set to `XTrue`). There are some additional util > functions, like `returnProgress` which behaves just like return, but also > sets the `XBool` value to `XTrue`: > > {{{#!hs > instance Monad m => MonadProgressParser (FailParser m) where > returnProgress a = FailParser $! pure (T XFalse a) ; {-# INLINE > returnProgress #-} -- In correct code it should be XTrue as described > below. > }}} > > In the provided code, there is `XFalse` used instead of `XTrue` because > of some interesting observations: > > 1. The `XBool` value is used ONLY in the expression `return $! T (b ||| > b') a'` above, so it does NOT affect the way the program logically > executes it's body. > > 2. Both `b` and `b'` are strict and fully evaluated. > > 3. If both `b` and `b'` are `XFalse` (as in the provided code, they > always are `XFalse`) we get a good performance. In order to test it, the > above code contains `XFalse` instead of `XTrue`. > > 4. If we use the correct version of `returnProgress` as described just > before point 1 above, we get 15 times slower performance (the same or > very similar to the one when used altered `evalStateT` definition). We > could try to explain it: maybe Haskell was able to optimize code if it > discovered, there always were only `XFalse` values used and after the > change there are both `XTrue` and `XFalse`, so it really has to run the > `(|||)` operator. This way of thinking fails as fast as we check that > changing `XFalse` to `XTrue` **everywhere** in the code give us again bad > performance. > > 5. If we replace `return $! T (b ||| b') a'` with `return $! T b' a'` we > get good performance, while replacing it with `return $! T b a'` give us > bad performance. It does not make any sense, because both `b` and `b'` > are strict and fully evaluated. Moreover, it is the only place in code > where they are used. > > 6. However replacing `return $! T (b ||| b') a'` with `return $! T (b' > ||| b) a'` does NOT change the performance (we are getting the good one). > > == Final notes > > We've been talking with some people - both in the company I'm working in > as well as on IRC and we do not see any reason why this code behaves in > this way and why it is so sensitive to the changes. In fact we started to > be worried a lot about how we can use Haskell for high-performance parts > at all, if it is not obvious if a very simple change do not affect > performance a lot. A good example is changing `evalStateT m = fmap fst . > runStateT m` to `evalStateT m a = fmap fst $ runStateT m a`, which gives > 15 times slowdown. This situation makes the source code both very fragile > to any changes as well as makes it unmaintainable. Tracking performance > in a very small program (like the attached one) is possible, while > tracking it in bigger one, taking in consideration the described > problems, make it almost impossible. I'm writing this because I'm worried > about where these problems originate from and I would really like to > solve them / know why they appear, and be sure we can continue to use > Haskell for our high-performance demanding applications. New description: Hi! I was recently testing performance of a critical code in a product we are shipping and I'm getting really weird results. **The code is compiled with `-XStrict` enabled globally. The full source code for this ticket is attached, while the exposed code below uses `...` to hide some non-important implementations.** To get desired results, we use following GHC flags: `-O2 -funfolding-use- threshold=10000`. Let's consider the following program. It is just a pseudo-parser implementation. It consumes 'a' chars in a loop and fails on empty input in the end: {{{#!hs -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -- | WARNING: -XStrict enabled in this file !!! -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! module Main where imports ... (full source attached to this ticket) ------------------------ -- === Primitives === -- ------------------------ -- === Strict Either === -- data Either e a = Left e | Right a deriving (Eq, Generic, Ord, Read, Show, Functor) newtype EitherT e m a = EitherT { runEitherT :: m (Either e a) } instance Monad m => Functor (EitherT e m) where ... instance Monad m => Applicative (EitherT e m) where ... instance Monad m => Monad (EitherT e m) where ... -- === Strict Bool === -- data XBool = XTrue | XFalse deriving (Show, Generic) (|||) :: XBool -> XBool -> XBool (|||) !a !b = case a of XTrue -> a XFalse -> b {-# INLINE (|||) #-} -- === Strict Tuple === -- data T a b = T !a !b deriving (Generic, Show, Functor) ------------------------ -- === FailParser === -- ------------------------ -- === Definition === -- -- | It is just like EitherT, but also contains progress indicator - a field of type XBool -- which tells us if we've already parsed a char or not yet. In this snippet code however, -- it does not do anything valuable - it just stores the value. newtype FailParser m a = FailParser { fromFailParser :: EitherT () m (T XBool a) } deriving (Functor) instance Monad m => Applicative (FailParser m) where pure = undefined (<*>) = undefined instance Monad m => Monad (FailParser m) where return a = FailParser $ return $ (T XFalse a) ; {-# INLINE return #-} FailParser ma >>= f = FailParser $ do T !b !a <- ma T !b' !a' <- fromFailParser $ f a return $ T (b ||| b') a' {-# INLINE (>>=) #-} _ >> _ = undefined ; {-# INLINE (>>) #-} -- === Running === -- failParser :: m (Either () (T XBool a)) -> FailParser m a failParser a = FailParser $ EitherT a ; {-# INLINE failParser #-} runFailParser :: forall m a. FailParser m a -> m (Either () (T XBool a)) runFailParser f = runEitherT $ fromFailParser f ; {-# INLINE runFailParser #-} -- === MonadFailedParser === -- -- | Behaves just like "left" - lifts until it hits MonadFailedParser class Monad m => MonadFailedParser m where failed :: m a instance {-# OVERLAPPABLE #-} (MonadFailedParser m, MonadTrans t, Monad (t m)) => MonadFailedParser (t m) where failed = lift failed ; {-# INLINE failed #-} instance Monad m => MonadFailedParser (FailParser m) where failed = failParser $ return $ Left () ; {-# INLINE failed #-} ----------------------- -- === Main loop === -- ----------------------- parserLoop :: StateT Text (FailParser Identity) Bool parserLoop = parserStep >> parserLoop parserStep :: StateT Text (FailParser Identity) Char parserStep = get >>= \s -> case Text.uncons s of Just (!t, !s') -> if t == 'a' then put s' >> return t else failed Nothing -> failed {-# INLINE parserStep #-} -- === Criterion === -- instance NFData XBool instance (NFData l, NFData r) => NFData (Either l r) instance (NFData a, NFData b) => NFData (T a b) genText :: Int -> Text genText i = fromString $ replicate i 'a' ; {-# INLINE genText #-} a_parsing_main :: IO () a_parsing_main = do defaultMain [ env (return $ genText $ 10^6) $ bench "a*" . nf (runIdentity . runFailParser . evalStateT parserLoop) ] main = a_parsing_main }}} The most important part is the `bind` implementation of `FailParser`: {{{#!hs FailParser ma >>= f = FailParser $ do T b a <- ma T b' a' <- fromFailParser $ f a return $ T (b ||| b') a' }}} There are several performance related observations and problems: 1. **INFO:** Everything is compiled with `-XStrict` and every field in this code is fully evaluated, in particular `b` and `b'` are fully evaluated, strict values of type `XBool`. 2. **INFO:** Neither `b` nor `b'` are used anywhere else in the code. They are just fields in `FailParser` which should be used to store information if we did consume a letter or we did not. 3. **PROBLEM:** When provided with `10^6` characters this code works in 1ms. If we replace `(b ||| b')` with `(b' ||| b)` or with `(b')` the time do NOT change. However, if we replace it with `(b)`, we've got **15 times** slowdown. Moreover, the resulting core is changed drastically in some places. 4. **PROBLEM:** Another interesting observation is that the value of `XBool` is created only in one place in the code, namely in: `FailParser`'s `Monad` implementation, in `return` function: `return a = FailParser $ return $ (T XFalse a) ; {-# INLINE return #-}`. We never change the XFalse, so this is the only value that could appear in this code. If we change it to `XTrue` in this implementation however, we again get **15 times** slowdown. 5. **INFO:** The order of `case` expressions in definition of `(|||)` or the order of constructor defintions of any datatype does not affect the above results. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:42:16 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by danilo2): * Attachment "Main.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:42:16 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.4d9efdd2a3bb8ed84a2c5f37b2c30b58@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by danilo2): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 20:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 20:48:57 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.a8bdb9050d9751372b07a8efd28e4b85@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 danilo2): I've just shortened the example code and made the performance related questions simpler. I think it would be easier now debug what is going on under the hood. I would be very thankful for any information regarding this issue. We've been talking with many people - both in the company I'm working in as well as on IRC and we do not see any reason why this code behaves in this way and why it is so sensitive to the changes. We started to be worried a lot about how we can use Haskell for high-performance parts at all, if it is not obvious if a very simple change do not affect performance a lot. This situation makes the source code both very fragile to any changes and unmaintainable as a result. I'm writing this because I'm deeply worried about where these problems originate from and I would really like to solve them / know why they appear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 21:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 21:53:15 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2314046=3A_=E2=80=9CIllegal_type_synonym_fa?= =?utf-8?q?mily_application_in_instance=E2=80=9D_is_too_strict_in?= =?utf-8?q?_the_presence_of_functional_dependencies?= Message-ID: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #3485 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC rejects the following instance, complaining about the use of a type synonym family in the instance head: {{{#!hs type family Fam a class Multi a b | a -> b instance Multi (Maybe a) (Fam a) }}} However, this seems too strict to me, since the second parameter of `Multi` is determined by a functional dependency. If I tweak the instance slightly to lift the second parameter out of the instance head into an equality constraint, GHC accepts the instance: {{{#!hs instance (b ~ Fam a) => Multi (Maybe a) b }}} It seems to me that, due to the functional dependency, these two instances are completely equivalent. Therefore, GHC should accept the first instance. This is similar to an old ticket, #3485, but that did not involve fundeps, so GHC’s error was correct. I’m pretty sure the addition of functional dependencies changes things, making the two actually equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 27 23:57:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Jul 2017 23:57:46 -0000 Subject: [GHC] #13430: Can't scope type variables when pattern matching on GADTs In-Reply-To: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> References: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> Message-ID: <062.725cd6d0600a3804ff6db462a2137412@haskell.org> #13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12018 Comment: I'm opting to close this as a duplicate of #12018. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 01:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 01:17:59 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.a991e62beb283d573e610647ce2a0581@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Thinking about the problem again I decided to try to add {{{ByteArray#}}} literals to GHC. The idea is the following: - Use {{{"foo"##}}} as syntax for {{{ByteArray#}}}s. This is in essence my try for a {{{String#}}} type. - Provide {{{#!haskell unpackStringLit# :: ByteArray# -> [Char] {-# INLINE[1] unpackStringLit# #-} unpackStringLit# ba# = unpackCStringWithLen# (byteArrayContents# ba#) (sizeofByteArray# ba#) }}} - Compile {{{"foo"}}} as {{{unpackStringLit# "foo"##}}} - Let rewrites fire in phase 2. - In phase 1, inline {{{unpackStringLit#}}} and let rules rewrite it to {{{unpackCStringWithLen# "foo"# 3#}}} - Thus most {{{ByteArray#}}}s should get eliminated and binary size should stay more or less the same. - If someone rewrites something like {{{ByteString.pack (unpackStringLit# lit)}}}, the literal is not eliminated and emitted to the binary. Thus a {{{ByteString}}} literal can increase binary size. However, I think this is what we want because we save making a copy of the data. - The downside is that turning optimization off causes the compiler to create a {{{ByteArray#}}} for every string literal instead of a c-string. GHCi will also allocate {{{ByteArray#}}}s instead of string literals directly. I currently implemented the new literal type, extended the parser, changed the desugaring, added the needed rules, taught GHCi to handle {{{ByteArray#}}} literals, and generated cmm Code for them. I still have to look at all parts involved for fusion and other string rules to work, check how the change affects bootstrapping with an older compiler, take a look at template haskell, and whether there are any typeable/generic things involved. I don't know how everyone feels about adding another literal type (especially because there are now two similar types, {{{Addr#}}} and {{{ByteArray#}}}, but if we want to keep binary sizes down, we need some form of {{{Addr#}}}, and it seems like having {{{ByteArray#}}} is beneficial too). Or whether it is reasonable to provide syntax for {{{ByteArray#}}}s (letting the compiler generate them would be enough for this ticket). But right now implementing it like this feels a lot better than my previous approach using unboxed tuples. And I am sorry for not saying or doing anything such a long time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 02:28:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 02:28:03 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.b2adf9a66c77b0eabd2aa907e369f01c@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 zaoqi): Replying to [comment:13 AntC]: > Replying to [comment:12 zaoqi]: > > Replying to [comment:11 AntC]: > > > > > > So `instance Eq Dyn` will always return False. > > > > How to write the correct `instance Eq Dyn`, do not change `data Dyn`. > > The short answer is: `data Dyn` has the wrong definition for looking inside. Ben has given you one possibility in comment:8. A more simple one is: > > {{{ > > data Dyn a where > Dyn :: Eq a => a -> Dyn a > > }}} > > If you can't change the definition of `Dyn` (why not?), you need to explain what you are trying to achieve. > > I suggest you ask a question on the cafe (or StackOverflow). GHC is behaving as intended. There's no fault, so Trac is not the place to look for that kind of help. (I see you've posted several Trac tickets that are not really faults.) > > Perhaps it would be easier for you to ask on a Chinese language forum? There seem to be [https://www.reddit.com/r/ChineseLanguage/comments/62qfze/is_there_a_chinese_app_that_is_equivalent_to/ some equivalents to reddit], for both Mandarin and Cantonese. `instance Dyn Ord` `instance Dyn Num` `instance Dyn Read` `instance Dyn Show` ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 03:10:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 03:10:03 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.43ce097bf47f4b81edecf8882a7b1592@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I working on preparing 6.1 bindists; unfortunately I'm having some build troubles so it will take a bit longer than anticipated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 04:27:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 04:27:11 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.9aeb8f048d1fbd891c5d03699c6a7991@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): Thank you, Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:11:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:11:47 -0000 Subject: [GHC] #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) In-Reply-To: <051.6f4adb265ab208b75b739851f1fb480c@haskell.org> References: <051.6f4adb265ab208b75b739851f1fb480c@haskell.org> Message-ID: <066.70522d846ebb5c52cdbd5aa40dc0d3b8@haskell.org> #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: GADTs, Resolution: | ScopedTypeVariables Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13430 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #13430 Comment: See also #13430 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:13:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:13:41 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.b6b2bb381d56883b064a98fae4f03d97@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:18:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:18:05 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.685546d7efe475ee2bea3376439ecba6@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: Iceland_jack (removed) Comment: Consider {{{ (A) instance (b ~ [c]) => C Int b vs (B) instance C Int [c] }}} These behave quite differently. (B) waits until the constraint to be solved looks like `C Int [something]` and then uses the instance. But (A) waits only until the constraint looks like `C Int something` and then fires the instance, generating a constraint `something ~ [c0]` where `c0` is a fresh unification variable. So for example `C Int t0`, where `t0` is a unification variable` will be solved by (A) but not by (B). It's similar with type families. I think you should write it in the (A) form if you want that behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:22:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:22:02 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.36bd769bc11ab482b185f31dc36c8cec@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: To me the `k` argument to `Sing` looks like an invisible (implicit) one. So you should need visible kind application to use it in an invocation, something like {{{ instance C (z :: Bool) where data Sing :: Bool -> Type where SFalse :: Sing @False STrue :: Sing @True }}} Let's see what Richard says. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:24:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:24:52 -0000 Subject: [GHC] #14042: Data type with type family in return kind spuriously rejected In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.c002bca742d0f508fd5d0fbff2354b4b@haskell.org> #14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by simonpj): There are other places where we don't accept a type-function application; e.g. {{{ type instance F Int = Bool instance C (F Int) where ... }}} And rightly so. This one is, I grant you, less justifiable. But I think it'd be fiddly to support, and the motivation seems weak. After all, data families always have result kind `*` so why not say so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 07:32:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 07:32:20 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.7c7f8e78c5247a5a563bc691a2a01ae6@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): Could you give me an example of a program with observably different behavior between the two instances? That is, given the thing being discussed, probably a program that typechecks under the presence of one instance but not the other. Without that, I’m not familiar enough with the precise details of how the constraint solver handles functional dependencies to understand the difference. Also, even if there ''is'' a meaningful difference, is it significant enough that it would make allowing the instance defined without the equality constraint meaningless or inconsistent? ---- The example I gave in the ticket is in something of a vacuum, so allow me to give an example of what actually caused this in the first place. Specifically, I was using the `lens` library’s TH function `makeFields` on a record type that had a type family application as the type of one of its fields. The code in question looked something like this: {{{#!hs type family Fam a data Rec a = Rec { _recValue :: Fam a } makeFields ''Rec }}} This effectively generates the following code: {{{#!hs class HasValue s a | s -> a where value :: Lens' s a instance HasValue (Rec a) (Fam a) where value = -- ... }}} …which raises the error. I opened [https://github.com/ekmett/lens/issues/754 ekmett/lens#754] to raise the issue with the `lens` folks directly, and I may very well attempt to solve the issue there myself by inserting the relevant Template Haskell checks and generating the equality constraint where necessary. I just figured it would make sense to ensure I wasn’t doing a lot of extra work to circumvent a possibly unnecessary restriction in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:08:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:08:33 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.0b10f23dd94738468b401c44f2236592@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > See: http://haskell.org/haskellwiki/Quantified_contexts > > Motivating example is collapsing insomeway-identical classes such as > Monoid and MonadPlus into a single class (with accompanying functions). New description: See: [wiki:QuantifiedContexts] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:27:36 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.f6ea14960ac56828f0918409d02c1802@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 simonpj): Are you sure? `newName` generate a TH `NameU`; and `Convert.thRdrName` converts a `NameU` to an `Exact` `RdrName`. No? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:30:25 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type Message-ID: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type --------------------------------------+--------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- This occured to me in `network-ip` package today: {{{#!hs {-# LANGUAGE StandaloneDeriving #-} module Repro where import Data.Typeable (Typeable1) data InetAddr a = InetAddr deriving instance Typeable1 InetAddr }}} Results in GHC complaining with: {{{#!hs repro.hs:7:19: error: * Illegal instance for a type synonym A class instance must be for a class * In the stand-alone deriving instance for `Typeable1 InetAddr' | 7 | deriving instance Typeable1 InetAddr | ^^^^^^^^^^^^^^^^^^ }}} This is due to `Typeable1` defined as type synonym for `Typeable` (see here http://hackage.haskell.org/package/base-4.10.0.0/docs/Data- Typeable.html#t:Typeable1). I can see it is deprecated but I would still expect it to work correctly still. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:31:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:31:43 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.9daf21d43b32b64baa2722d13f156c61@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type ---------------------------------+-------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by alexbiehl: Old description: > This occured to me in `network-ip` package today: > > {{{#!hs > {-# LANGUAGE StandaloneDeriving #-} > module Repro where > > import Data.Typeable (Typeable1) > > data InetAddr a = InetAddr > deriving instance Typeable1 InetAddr > }}} > > Results in GHC complaining with: > > {{{#!hs > repro.hs:7:19: error: > * Illegal instance for a type synonym > A class instance must be for a class > * In the stand-alone deriving instance for `Typeable1 InetAddr' > | > 7 | deriving instance Typeable1 InetAddr > | ^^^^^^^^^^^^^^^^^^ > }}} > > This is due to `Typeable1` defined as type synonym for `Typeable` (see > here http://hackage.haskell.org/package/base-4.10.0.0/docs/Data- > Typeable.html#t:Typeable1). > > I can see it is deprecated but I would still expect it to work correctly > still. New description: This occured to me in `network-ip` package today: {{{#!hs {-# LANGUAGE StandaloneDeriving #-} module Repro where import Data.Typeable (Typeable1) data InetAddr a = InetAddr deriving instance Typeable1 InetAddr }}} Results in GHC complaining with: {{{#!hs repro.hs:7:19: error: * Illegal instance for a type synonym A class instance must be for a class * In the stand-alone deriving instance for `Typeable1 InetAddr' | 7 | deriving instance Typeable1 InetAddr | ^^^^^^^^^^^^^^^^^^ }}} This is due to `Typeable1` defined as type synonym for `Typeable` (see here http://hackage.haskell.org/package/base-4.10.0.0/docs/Data- Typeable.html#t:Typeable1). I see it is deprecated but I would still expect it to work correctly still. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:34:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:34:57 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.5c6f5e3befbdc746f59da00d62020a28@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): > When provided with 10^6 characters this code works in 1ms Can you provide test data. How do I run the program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:41:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:41:44 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.6de4c5e5c1533c32f02267a1d9bf79fe@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type ---------------------------------+-------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by alexbiehl): I should mention this actually worked with ghc-8.0.2 as it also uses a type synonym for `Typeable1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:56:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:56:23 -0000 Subject: [GHC] #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination In-Reply-To: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> References: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> Message-ID: <062.2c7cd32fa65587c44d6340d55fecb9ef@haskell.org> #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms 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 Simon Peyton Jones ): In [changeset:"6b77914cd37b697354611bcd87897885c1e5b4a6/ghc" 6b77914/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b77914cd37b697354611bcd87897885c1e5b4a6" Fix instantiation of pattern synonyms In Check.hs (pattern match ovelap checking) we to figure out the instantiation of a pattern synonym from the type of the pattern. We were doing this utterly wrongly. Trac #13768 demonstrated this bogosity. The fix is easy; and is described in PatSyn.hs Note [Pattern synonym result type] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:56:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:56:23 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.59e2347d46763b8d80d16bce984f274b@haskell.org> #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b1317a35770b19838c7f6b07e794bfc61419e889/ghc" b1317a3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1317a35770b19838c7f6b07e794bfc61419e889" Fix ASSERT failure in tc269 This ASSERT failure (in substTy) was reported in Trac #14024. This patch gets the in-scope set right. (Does not fix tests T13822 or T13594.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:56:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:56:23 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.b5b1539f3e99f4c7ad22d813368c75e2@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"452755de717fad5d8fbfc6330cb42a3335c8912d/ghc" 452755de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="452755de717fad5d8fbfc6330cb42a3335c8912d" Do not discard insolubles in implications Trac #14000 showed up two errors * In TcRnTypes.dropInsolubles we dropped all implications, which might contain the very insolubles we wanted to keep. This was an outright error, and is why the out-of-scope error was actually lost altogether in Trac #14000 * In TcSimplify.simplifyInfer, if there are definite (insoluble) errors, it's better to suppress the following ambiguity test, because the type may be bogus anyway. See TcSimplify Note [Quantification with errors]. This fix seems a bit clunky, but it'll do for now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 08:56:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 08:56:23 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.332bba79ad1efe7973ca8f52806b8264@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ad0037ea3ea0eb9e2e693fa10f2171611c4e2217/ghc" ad0037e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad0037ea3ea0eb9e2e693fa10f2171611c4e2217" Add DebugCallStack to piResultTy This was provoked by an ASSERT failure when debugging #14038, but it's a godo idea anyway. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 09:23:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 09:23:27 -0000 Subject: [GHC] #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination In-Reply-To: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> References: <047.c95bd0aba0dc6c9a98656f56c98cf18b@haskell.org> Message-ID: <062.4a6a0392f763d846576e1cb0e072543c@haskell.org> #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T13768 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/T13768 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 09:24:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 09:24:46 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.1581e2d8bdf0ad358c34d44f4e584ab2@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T14000 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T14000 * resolution: => fixed Comment: Excellent report; fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 09:25:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 09:25:10 -0000 Subject: [GHC] #14000: Out of scope errors with type families do not mention scope In-Reply-To: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> References: <048.64d0bc411ba7b3b996d735f797943d02@haskell.org> Message-ID: <063.fe3a67c5598c0a16a3352f17219ed7fe@haskell.org> #14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T14000 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge * milestone: => 8.2.2 Comment: Might be worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 12:11:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 12:11:53 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.f6a1a751e6deb45860cb9d7b862008d1@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: new => patch * differential: => Phab:D3800 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 12:24:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 12:24:23 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.36193186df6e7f7f76eb846736d445e7@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: fixed | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. In `Match.hs` this patch did {{{ - ; let upats = map (unLoc . decideBangHood dflags) pats + ; let add_bang + | FunRhs {mc_strictness=SrcStrict} <- ctx + = pprTrace "addBang" empty addBang + | otherwise + = decideBangHood dflags + upats = map (unLoc . add_bang) pats }}} I don't think that's right. I claim the if `mc_strictness` is True then `pats` is empty, so this change is a no-op. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:00:07 -0000 Subject: [GHC] #14048: Data instances of kind Constraint Message-ID: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Continuation of #12369. Allow data instances ending in `Constraint`. This may be a bug but GHC already accepts (something to do with #11715) `data family Bot :: Constraint` but I can't make instances of it. Also fails for `data family Bot :: TYPE IntRep`. I propose letting users take these disparate data types and type classes {{{#!hs data Compose :: (k' -> Type) -> (k -> k') -> (k -> Type) where Compose :: f (g a) -> Compose f g a data Compose2 :: (k' -> (kk -> Type)) -> (k -> k') -> (k -> (kk -> Type)) where Compose2 :: f (g a) b -> Compose2 f g a b -- ComposeC :: (k' -> Constraint) -> (k -> k') -> (k -> Constraint) class f (g a) => ComposeC f g a instance f (g a) => ComposeC f g a -- ComposeC2 :: (k' -> (kk -> Constraint)) -> (k -> k') -> (k -> (kk -> Constraint)) class f (g a) b => ComposeC2 f g a b instance f (g a) b => ComposeC2 f g a b }}} and unify them as instances of a 'data' family indexed by `Type`, `kk -> Type`, `Constraint`, `kk -> Constraint`. (Same can be done for `Data.Functor.Product` and `class (f a, g a) => ProductC f g a`): {{{#!hs data family (·) :: (k' -> k'') -> (k -> k') -> (k -> k'') data instance (f · g) a where Compose :: f (g a) -> (f · g) a data instance (f · g) a b where Compose2 :: f (g a) b -> (f · g) a b instance f (g a) => (f · g) a instance f (g a) b => (f · g) a b }}} ---- TODO Once we have #1311 allow data instances of unlifted types. ---- Fun note: `(·) @(kk -> Type)` is used by [https://gist.github.com/ekmett/48f1b578cadeeaeee7a309ec6933d7ec Kmett] (as `Tensor`) & to motivate [http://i.cs.hku.hk/~bruno/papers/hs2017.pdf quantified class constraints], this should automatically pick the right data instance: {{{#!hs instance (Trans t, Trans t') => Trans (t · t') where lift :: Monad m => m ~> (t · t') m lift = Compose2 . lift @t . lift @t' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:17:42 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.9e8a75bfb5cbe23651f147b71f435f8e@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): jscholl, I was speaking to phadej yesterday and he also sounded interested in looking at this problem. Regardless of what happens, this is a change to the user-facing interface provided by the compiler and consequently falls under the [[https://github.com/ghc-proposals/ghc-proposals|GHC proposal process]]. Do you think you could write a proposal explaining your approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:29:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:29:03 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.654e09c70f7ba8b56d75fed0c29951f2@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13267 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #13267 Comment: This is expected behavior, see #13267. As it turns out, allowing type synonyms to be used as instance heads is extremely tricky to get right, and GHC decided to disallow this in 8.2.1 due to incorrect results one could achieve with nonsense like: {{{ type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} As for your particular program, the workaround is simple: just don't derive `Typeable`! Every type automatically has `Typeable` instances these days, so deriving `Typeable` is a no-op. As you've noted `Typeable1` //et al.// have long been deprecated in favor of `Typeable`, and given that they're far less useful than they were in the past, I propose just removing `Typeable1` and friends altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:30:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:30:19 -0000 Subject: [GHC] #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type In-Reply-To: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> References: <048.e36df34c52da0449ddb629cfe957c27e@haskell.org> Message-ID: <063.d6146fc5141e2860c81930a5957b3d33@haskell.org> #14047: "Illegal instance for type synonym" while deriving Typeable1 for data type -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13267 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Thank you Ryan. I will PR said package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:44:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:44:52 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.5c380d4ece11258ec603ae1e01dbe28e@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): My apologies, I was mistakenly under the impression that `NameU`s weren't exact. As for the idea of having GHC accept collisions between two `Exact` names with the same `nameBase` but different uniques... the idea still makes me a little bit queasy. I can think of a couple of unfortunate consequences of permitting this: 1. The fact that the program in comment:9 would still be ambiguous. Allowing `newName` to create valid top-level names means that you can effectively only use them from Template Haskell code in the event you use `newName` to create multiple copies of the same name. If you did such a thing, any attempt to use one copy of the name would result in ambiguity. This means that exporting them, importing them, using them in user- written source code, etc. is a no-go. This really feels like the wrong design to me—we shouldn't be encouraging the use of such a fragile mechanism. 2. How will Haddock render two top-level names with the same `nameBase` generated with two different calls to `newName`? Haddock would pretty much have to render the same function names twice, which is bound to cause confusion for readers. On the other hand `newGlobalName` would not be subject to these flaws. Because names produced by `newGlobalName` are truly unique (due to the suffix attached to them), no problems emerge from calling `newGlobalName` twice with the same `nameBase`. (I'm aware that programs like comment:9 aren't the intended //purpose// of `newGlobalName`, but it would be nice to rule out such tomfoolery by construction.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:50:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:50:27 -0000 Subject: [GHC] #14049: relax -Wmissing-import-lists to allow one module without implicit imports when using NoImplicitPrelude Message-ID: <051.cb09fea0059e08165db4130c65661514@haskell.org> #14049: relax -Wmissing-import-lists to allow one module without implicit imports when using NoImplicitPrelude -------------------------------------+------------------------------------- Reporter: cdepillabout | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- It would be nice to modify the `-Wmissing-import-lists` warning flag to allow one module with implicit imports when using the `NoImplicitPrelude` pragma. For example, imagine the following program: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} module Main where import MyCustomPrelude import Control.Monad.Trans.Reader (Reader, runReader) what :: Reader Int String -> String what x = runReader x 3 main :: IO () main = print "hello" }}} If this program is compiled with the `-Wmissing-import-lists` flag, the following warning will be produced: {{{ example.hs:5:1: warning: [-Wmissing-import-lists] The module ‘MyCustomPrelude’ does not have an explicit import list }}} I think it would be nice if this warning did not appear. Ideally, when using `NoImplicitPrelude` and `-Wmissing-import-lists` together, I would want one import per module to be permitted not to be explicit. This would make it possible to use an alternative Prelude and `-Wmissing-import-lists` at the same time. Alternatively, a new warning flag could be created with the above behavior. Maybe it could be called something like `-Wmulti-implicit- imports` or `-Wmulti-open-imports`. I would appreciate feedback/suggestions for the name. ---- PureScript currently works like I have described above. By default the `Prelude` module is not imported (so you must explicitly import it), and the compiler will warn you if you have more than one implicit import. I really like this combination and it would be nice to be able to get the same thing in Haskell. In case anyone is interested, [https://github.com/purescript/purescript/issues/1869 here] is the issue for PureScript where they talked about making this change. ---- If it seems like this is a good idea and other people are onboard, I'd be willing to implement it. I think it would be a relatively easy change, so it would be good for a first-time contributor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 13:57:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 13:57:26 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.490002b9a01d5f890094b2cce420eaca@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rtfeldman): * cc: rtfeldman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 14:09:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 14:09:15 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.fc7aa4aa4484b3c2c8f98f98f32f0f4a@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): jscholl, I'd like to participate on the proposal, bgamari mentioned above. I really think we (= community) should design this properly, as you mentioned `Addr#` and `ByteArray#` are confusing. Also Unicode/encodings add some complexity. The reward, is that we can close many tickets (at least #11312 with "single" change. I still try to wrap my head around internals, and my friends' weading is in 20 hours, so I'll return to this only next week -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 14:39:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 14:39:24 -0000 Subject: [GHC] #14049: relax -Wmissing-import-lists to allow one module with implicit imports when using NoImplicitPrelude (was: relax -Wmissing-import-lists to allow one module without implicit imports when using NoImplicitPrelude) In-Reply-To: <051.cb09fea0059e08165db4130c65661514@haskell.org> References: <051.cb09fea0059e08165db4130c65661514@haskell.org> Message-ID: <066.c1d5445d273edee16f50218e1d38aa63@haskell.org> #14049: relax -Wmissing-import-lists to allow one module with implicit imports when using NoImplicitPrelude -------------------------------------+------------------------------------- Reporter: cdepillabout | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 14:54:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 14:54:42 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.19a8a115feb6f1551aa11625451c256a@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Hopefully Phab:D2309 will help improve register allocation in cases like these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:27:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:27:38 -0000 Subject: [GHC] #14042: Data type with type family in return kind spuriously rejected In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.f29e9df101176c708c6f4087e12ad511@haskell.org> #14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Fair enough, I can accept GHC rejecting occurrences of type families in data type return kinds. But at the very least the error message ought to be changed here, because the current one misleads readers from the real problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:33:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:33:49 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.549726d97b425e947757d45e96df830f@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Did you mean Phab:D2903? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:52:21 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.6c5d5996514040f133087368051d16a9@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"424ecadbb3d06f4d4e0813de670369893e1da2a9/ghc" 424ecadb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="424ecadbb3d06f4d4e0813de670369893e1da2a9" Add regression tests for #13601, #13780, #13877 Summary: Some recent commits happened to fix other issues: * c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 fixed #13601 and #13780 * 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 fixed the original program in #13877 Let's add regression tests for each of these to ensure they stay fixed. Test Plan: make test TEST="T13601 T13780a T13780c T13877" Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13601, #13780, #13877 Differential Revision: https://phabricator.haskell.org/D3794 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:52:21 -0000 Subject: [GHC] #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error In-Reply-To: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> References: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> Message-ID: <065.688636bafccd679113b28bd1bb2c6471@haskell.org> #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | 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): Phab:D3793 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"d6186496d414638aa66a677bb4e555dba376ec97/ghc" d6186496/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6186496d414638aa66a677bb4e555dba376ec97" Error eagerly after renaming failures in reifyInstances Summary: Previously, if `reifyInstances` failed to discover a `Name` during renaming, it would blindy charge into typechecking, at which point GHC would become very confused at the absence of that `Name` and throw an internal error. A simple workaround is to fail eagerly after renaming errors. Test Plan: make test TEST=T13837 Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13837 Differential Revision: https://phabricator.haskell.org/D3793 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:52:21 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.45bd525f7dc8dfc9f49330693b13f30e@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3751 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b3b564fbc0ceb06e6a880289935449fda7d33f31/ghc" b3b564fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3b564fbc0ceb06e6a880289935449fda7d33f31" Merge types and kinds in DsMeta Summary: Types and kinds are now the same in GHC... well, except in the code that involves Template Haskell, where types and kinds are given separate treatment. This aims to unify that treatment in the `DsMeta` module. The gist of this patch is replacing all uses of `repLKind` with `repLTy`. This is isn't quite as simple as one might imagine, since `repLTy` returns a `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a `Core Kind` (a pure expression). This causes many awkward impedance mismatches. One option would be to change every combinator in `Language.Haskell.TH.Lib` to take `KindQ` as an argument instead of `Kind`. But this would be a breaking change of colossal proportions. Instead, this patch takes a somewhat different approach. This migrates the existing `Language.Haskell.TH.Lib` module to `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new `Language.Haskell.TH.Lib` module then re-exports most of `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related combinators, for which it redefines them to be their current definitions (which don't live in `Q`). This allows us to retain backwards compatibility with previous `template-haskell` releases, but more importantly, it allows GHC to make as many changes to the `Internal` code as it wants for its purposes without fear of disrupting the public API. This solves half of #11785 (the other half being `TcSplice`). Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #11785 Differential Revision: https://phabricator.haskell.org/D3751 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:52:21 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.071c01b240c8359876d8d1fda66cf06f@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"424ecadbb3d06f4d4e0813de670369893e1da2a9/ghc" 424ecadb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="424ecadbb3d06f4d4e0813de670369893e1da2a9" Add regression tests for #13601, #13780, #13877 Summary: Some recent commits happened to fix other issues: * c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 fixed #13601 and #13780 * 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 fixed the original program in #13877 Let's add regression tests for each of these to ensure they stay fixed. Test Plan: make test TEST="T13601 T13780a T13780c T13877" Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13601, #13780, #13877 Differential Revision: https://phabricator.haskell.org/D3794 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:52:21 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.a2e4586e9b4235238d3e6d02e4485918@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13910, #14040 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"424ecadbb3d06f4d4e0813de670369893e1da2a9/ghc" 424ecadb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="424ecadbb3d06f4d4e0813de670369893e1da2a9" Add regression tests for #13601, #13780, #13877 Summary: Some recent commits happened to fix other issues: * c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 fixed #13601 and #13780 * 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 fixed the original program in #13877 Let's add regression tests for each of these to ensure they stay fixed. Test Plan: make test TEST="T13601 T13780a T13780c T13877" Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13601, #13780, #13877 Differential Revision: https://phabricator.haskell.org/D3794 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:54:17 -0000 Subject: [GHC] #13877: GHC panic: No skolem info: k2 In-Reply-To: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> References: <050.85aac3d842c3e1851a442a13f59ce985@haskell.org> Message-ID: <065.8af0ffb08401bad013c6f46f59b962ae@haskell.org> #13877: GHC panic: No skolem info: k2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_fail/T13877 Blocked By: | Blocking: Related Tickets: #13910, #14040 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => indexed-types/should_fail/T13877 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:55:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:55:30 -0000 Subject: [GHC] #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message In-Reply-To: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> References: <050.1bf0abe11448fb7d29d255c23fc5b878@haskell.org> Message-ID: <065.80f97cb9797a0babb2e46004c03d25e2@haskell.org> #13780: Nightmarish pretty-printing of equality type in GHC 8.2 error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | dependent/should_fail/T13780a, | dependent/should_fail/T13780c Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/should_fail/T13780a, dependent/should_fail/T13780c * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:56:20 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.f8f01d9e122af3ad4c07a2fdf97a02cf@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13601 Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Phab:D3794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/should_fail/T13601 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 15:56:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 15:56:50 -0000 Subject: [GHC] #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error In-Reply-To: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> References: <050.2ec8c837e6eed6426d66e4f53ccb99d0@haskell.org> Message-ID: <065.cbc998c1c804cfd0f509526e863b9774@haskell.org> #13837: Calling qReifyInstances on out-of-scope Name leads to GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T13837 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3793 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T13837 * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 16:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 16:37:00 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.07627282f788e094e92340c24e1b5d9d@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: ghc panic | impossible Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T14028 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"262bb95f5e00eea783d3e756fe86d96839be45d7/ghc" 262bb95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="262bb95f5e00eea783d3e756fe86d96839be45d7" testsuite: Add test for #14028 Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14028 Differential Revision: https://phabricator.haskell.org/D3788 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 16:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 16:37:00 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.00f1abc85ce3cb6a0a17bd65969a4005@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.0.1 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 Ben Gamari ): In [changeset:"5e940bd3d554729ce650008a72b4f82a78578a7b/ghc" 5e940bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e940bd3d554729ce650008a72b4f82a78578a7b" Switched out optparse for argparse in runtests.py Tangentially related to my prior work on trac ticket #12758. Signed-off-by: Jared Weakly Reviewers: austin, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3792 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 16:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 16:37:00 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.b8a388014c3006844e14cb32cb532de9@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 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 Ben Gamari ): In [changeset:"54d3a1fdeb7044a1d9bb025d4880d08c708b4cd0/ghc" 54d3a1f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="54d3a1fdeb7044a1d9bb025d4880d08c708b4cd0" testsuite: Produce JUnit output Test Plan: Validate, try ingesting into Jenkins. Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13716 Differential Revision: https://phabricator.haskell.org/D3796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 16:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 16:37:00 -0000 Subject: [GHC] #13825: Allow multiple constructor fields occupy the same word In-Reply-To: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> References: <046.a33ec6522f3fa0ad8c7d0d60af2159aa@haskell.org> Message-ID: <061.f1565bc428279e25380cf977dadfd7fd@haskell.org> #13825: Allow multiple constructor fields occupy the same word -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #605 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dac4b9d3cdca83c99d5d894d2743cc0bbca450ac/ghc" dac4b9d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dac4b9d3cdca83c99d5d894d2743cc0bbca450ac" ByteCodeGen: use byte indexing for BCenv This is another change needed for #13825 (also based on D38 by Simon Marlow). With the change, we count the stack depth in bytes (instead of words). We also introduce some `newtype`s to help with the change. Note that this only changes how `ByteCodeGen` works and shouldn't affect the generated bytecode. Signed-off-by: Michal Terepeta Test Plan: ./validate Reviewers: bgamari, simonmar, austin, hvr Reviewed By: bgamari, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3746 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 16:46:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 16:46:58 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.6252aee044acee39b84a9643b1c42bd7@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I have made some progress. (1), I discovered that `-XStrict` was generating some stunningly bad desugarings for very ordinary function bindings. I have a fix in the works. This seems to be responsible for almost all the performance loss. (2), look at your code {{{ FailParser ma >>= f = FailParser $ do T b a <- ma T b' a' <- fromFailParser $ f a return $ T (b ||| b') a' }}} If `b` turns out to be `XFalse`, this amounts to {{{ FailParser ma >>= f = FailParser $ do T b a <- ma T b' a' <- fromFailParser $ f a return $ T b' a' }}} and GHC can re-use the (T b' a') that `fromFailParser` returned. Moreover in the critical inner loop `b` is indeed `XFalse`: {{{ parserLoop = parserStep >> parserLoop }}} because `return` returns `XFalse`. But if you change the `(>==)` to {{{ return $ T b a' }}} now GHC can't re-use anthing, and so allocate a fresh `T` every time round the loop. So an apparently simpler program is actually more complicated! But (2) is not a massive effect. The big thing is the desugaring. Stay tuned. Meanwhile, try without `-XStrict`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 17:07:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 17:07:37 -0000 Subject: [GHC] #14042: Data type with type family in return kind spuriously rejected In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.df0d86319b1849bae0e0cc2e02332eb7@haskell.org> #14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType, TypeFamilies => TypeInType, TypeFamilies, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 17:08:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 17:08:16 -0000 Subject: [GHC] #14042: Misleading error message when type family is used in datatype's return kind (was: Data type with type family in return kind spuriously rejected) In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.9061fe8a834abc26bece17e3fbc5ad08@haskell.org> #14042: Misleading error message when type family is used in datatype's return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 17:35:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 17:35:50 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.f98af29b518d3e0447512203e5b842a8@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13810, #13739 | Differential Rev(s): Phab:D3449, Wiki Page: | Phab:D3694 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d08b9ccdf2812e8f8fa34d0c89275deee574524c/ghc" d08b9ccd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d08b9ccdf2812e8f8fa34d0c89275deee574524c" configure: Ensure that user's LD setting is respected This broke in the fix for #13541. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 18:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 18:18:12 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.8f690d579ef131539fa70656a8a6cd5b@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, good catch, RyanGlScott. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 18:44:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 18:44:54 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.3dbf4423f485561e285a20c87162ee85@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11958 * blockedby: => 13897 Comment: #13897 needs to be resolved before we can move forward on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 18:59:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 18:59:42 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.02d50e874052860b8362db9ef750624d@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 danilo2): Simon, first of all, thank you very much for your time and help with this topic! I added some important notices to the points mentioned in your response: **(1)** I'm so happy that you've found out that something is wrong and you've got fix for that! In generall, `-XStrict` is awesome, we need it in high performance Haskell code, putting bangs everywhere (and remembering about it) could be cumbersome. **(2)** You're of course right. I just opened the browser to add comment exactly about the same finding. The specification of `(|||)` allows GHC to easily discover that if we always use `XFalse` value, it could shorten the mentioned code to `s@(T b' a') <- fromFailParser $ f a ; return s` (just reuse the value). There are however 3 other non-obvious questions involved: **(2a)** Why GHC is able to optimize the code this way if we use everywhere `-XFalse` but it does not when using everywhere `-XTrue`? Very similar final core could be generated in the later case – if `b` is `XFalse` we can just reuse the output value, if it is `XTrue` we can be sure the output always contains `XTrue` as well. **(2b)** Even if GHC needs to create code like `T b' a' <- fromFailParser $ f a ; return $ T something a'`, why it takes so long? This is a strict, fully evaluated value, so why "updating a field" takes 10x longer than Char comparison? **(2c)** Moreover, what is the reason to "allocate a fresh `T` every time round the loop"? The fields of the tuple `T` do not "interact" with each other, they are just 2 separate outputs from a function. I could of course be very wrong, but I think it should be possible to just optimize `T a b` to `(# a,b #)` and cut the "fresh `T` allocation time" completely out, am I right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 20:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 20:20:01 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.a84d94dfaf54ab29e1030702e4b9abd5@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3717, Wiki Page: | Phab:D3802 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D3717 => Phab:D3717, Phab:D3802 Comment: I found yet another example of this sort of thing: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Data.Proxy import GHC.Generics import Language.Haskell.TH main :: IO () main = do putStrLn $([t| Proxy (:*:) |] >>= stringE . pprint) putStrLn $([t| Proxy '(:*:) |] >>= stringE . pprint) putStrLn $([t| Proxy '(:) |] >>= stringE . pprint) }}} {{{ Data.Proxy.Proxy (GHC.Generics.:*:) Data.Proxy.Proxy 'GHC.Generics.:*: Data.Proxy.Proxy 'GHC.Types.: }}} Unfortunately, we must have overlooked applying this fix to //promoted// infix constructors. I've got a patch at Phab:D3802 which addresses this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 20:22:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 20:22:36 -0000 Subject: [GHC] #14050: GHC HEAD test suite is broken with Python 3.4.3 Message-ID: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> #14050: GHC HEAD test suite is broken with Python 3.4.3 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 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: -------------------------------------+------------------------------------- After commit 5e940bd3d554729ce650008a72b4f82a78578a7b, I'm unable to run the GHC test suite on my machine: {{{ ghc2/testsuite$ make test make -C ./tests test make[1]: Entering directory `/home/rgscott/Software/ghc2/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=True -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config- file=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' -e 'config.top="/home/rgscott/Software/ghc2/testsuite"' --config 'compiler="/home/rgscott/Software/ghc2/inplace/test spaces/ghc-stage2"' --config 'ghc_pkg="/home/rgscott/Software/ghc2/inplace/test spaces/ghc- pkg"' --config 'haddock=' --config 'hp2ps="/home/rgscott/Software/ghc2/inplace/test spaces/hp2ps"' --config 'hpc="/home/rgscott/Software/ghc2/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout"' -e "config.stage=2" --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc- compact/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries /template-haskell/tests --rootdir=../../libraries/unix/tests \ \ \ \ \ \ \ Traceback (most recent call last): File "../driver/runtests.py", line 46, in allow_abbrev=False) TypeError: __init__() got an unexpected keyword argument 'allow_abbrev' make[1]: *** [test] Error 1 make[1]: Leaving directory `/home/rgscott/Software/ghc2/testsuite/tests' make: *** [test] Error 2 }}} geekosaur mentioned that my version of Python is likely to be important: {{{ $ python3 --version Python 3.4.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 21:28:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 21:28:15 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.338daef4504640022fdb88c42f8994b2@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 danilo2): One more important thing to note here is that the provided code was shortened to the limits. It does not use the `XBool` value in any place (it puts `-XFalse` everywhere, even after successful parse). It implies that the problem (2a) is also not very important - it is just an optimization opportunity in a very special and rare use case. We can easily fix the code and make it a real use case by inserting the following code: {{{#!hs class Monad m => ProgressMonad m where returnProgressed :: forall a. a -> m a instance {-# OVERLAPPABLE #-} (ProgressMonad m, Monad (t m), MonadTrans t) => ProgressMonad (t m) where returnProgressed = lift . returnProgressed ; {-# INLINE returnProgressed #-} instance Monad m => ProgressMonad (FailParser m) where returnProgressed a = failParser $ return $ Right $ T XTrue a ; {-# INLINE returnProgressed #-} }}} and replacing the line 125 to: {{{#!hs Just (!t, !s') -> if t == 'a' then put s' >> returnProgressed t else failed }}} The `XBool` value would then be used to implement `Alternative` instance, but we do not need it here. We can observe the same slowdown (`10^6` chars parsed in 15ms with `-XStrict` enabled). Which is expected, based on the results so far, however if we want to base on a real use case, this code help us transform abstract program to real one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 21:32:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 21:32:21 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.0207aa916efe77eeecd9d3a060e1b998@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a larger feature request than just a relaxation of kind checking. It requires, e. g. the syntax for declaring a class instance for a data family. I think this is a large enough delta on the current intentions for data families that it should properly be a ghc-proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 21:40:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 21:40:43 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.f47c1ea8f13f5bfbd1dd966dc413bd44@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Currently we use Harbormaster to build Differentials and commits. While > this works, it leaves much to be desired, > > * job scheduling is (literally) random: this means that some patch > authors end up waiting literally ways for their patches to be built > * there is little support for automatic provisioning of builders: this > means we can't scale to meet demand and make poor use of our > computational resources > * periodic builds (e.g. nightlies) are not supported. Ideally we would > not only provide > * it doesn't have a sensible interface for integration with external > tools: this means that efforts like CI-before-merge have been pushed off > * status reporting is poor: even answering the question of what a given > builder is currently working on is surprisingly difficult > * maintenance is a byzantine: Adding a new builder requires adding at > least six different objects (a Harbormaster Build Plan, a Drydock Working > Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an > Almanac Binding) in various Phabricator applications. None of this > configuration can be tracked under version control nor can most of it be > cloned from an existing builder's configuration. > * Design assumptions don't match GHC's constraints: Harbormaster was > designed under the assumption that builds are cheap and computation > plentiful. The maintainers have stated that they have little interest in > supporting environments where this doesn't hold. > > Jenkins, while far from perfect, seems a bit better suited to our needs, > more mature, and far more flexible. This ticket will serve as the > checklist for our move to Jenkins. > > In the end we want, > > * Builders (static or dynamically-provisioned, as appropriate) for > * x86-64, i386 Linux > * x86-64, i386 Windows > * x86-64 Darwin > * x86-64 OpenBSD > * Cross compile from x86-64 to ARM > * Native ARM > > * Differential builds with sensible scheduling (e.g. first build on > 64-bit Linux where machines are cheap, then build on the others) > * Per-commit builds on all > * Nightly builds on all, including > * Collection of binary distribution for user download > * Update of `master` documentation mirror on downloads.haskell.org > * Slow validation (including tests requiring Hackage packages) > * nofib run on some platforms? > * Test-before-merge-to-master New description: Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired, * job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built * there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources * periodic builds (e.g. nightlies) are not supported. * it lacks a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off * status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult * maintenance is a byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration. * Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold. Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins. In the end we want, * Builders (static or dynamically-provisioned, as appropriate) for * x86-64, i386 Linux * x86-64, i386 Windows * x86-64 Darwin * x86-64 OpenBSD * Cross compile from x86-64 to ARM * Native ARM * Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others) * Per-commit builds on all * Nightly builds on all, including * Collection of binary distribution for user download * Update of `master` documentation mirror on downloads.haskell.org * Slow validation (including tests requiring Hackage packages) * nofib run on some platforms? * Test-before-merge-to-master -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 22:10:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 22:10:31 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.4cf1165e5331ab44603e396a3f7d7d05@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): OK I have now also checked the situation on Windows: Windows `select()` does not set the `timeout` parameter to the remaining time. So currently `fdReady()` on Windows is as wrong as it is for the BSDs, and may wait forever even if given a max timeout. Source: https://msdn.microsoft.com/en- us/library/windows/desktop/ms740141(v=vs.85).aspx {{{ _In_ const struct timeval *timeout }}} I'll try to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 28 22:22:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Jul 2017 22:22:48 -0000 Subject: [GHC] #14050: GHC HEAD test suite is broken with Python 3.4.3 In-Reply-To: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> References: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> Message-ID: <065.f3cbe029f8916975468814bd56ba235e@haskell.org> #14050: GHC HEAD test suite is broken with Python 3.4.3 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3803 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3803 Comment: I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 00:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 00:29:02 -0000 Subject: [GHC] #12989: ($) can have a more general type In-Reply-To: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> References: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> Message-ID: <060.99bff654982e7e68023d8da48678be31@haskell.org> #12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism 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 andrewthad): One drawback of giving `($)` the more general type is than `(&)` can no longer be made symmetric with it. That is, we have no way of writing: {{{ (&) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> (a -> b) -> b }}} This probably isn't that big of a deal, but it is a little weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 03:03:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 03:03:45 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 Message-ID: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://www.reddit.com/r/haskell/comments/6q6yau/unboxed_sums_ghc_panic/ here]. You'll need these two files: {{{#!hs -- Testing.hs {-# LANGUAGE UnboxedSums #-} module Testing where func :: s -> (# Bool | Bool #) func _ = (# True | #) }}} {{{#!hs -- Bug.hs {-# LANGUAGE UnboxedSums #-} module Main where import Testing main :: IO () main = print $ func 1 }}} And you must compile them like so (the `-c` and `-O2` flags are important): {{{ $ ghc -O2 -c Testing.hs $ ghc -O2 -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): getUnboxedSumName 513 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/prelude/KnownUniques.hs:104:5 in ghc:KnownUniques }}} Reproducible with GHC 8.2.1 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 03:11:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 03:11:32 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.cce177aee8779a291ef7fbf0f9c81b7f@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D3804 Comment: Well, that's embarrassing. Easy enough to fix, but annoying to get good error messages in the mismatched associated type case (comment:2, which I think should be rejected). I'm afraid I think comment:3 is in error -- I don't understand what you're getting at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 03:15:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 03:15:31 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.bc96e476281b87d3e1e99ef40b8280ef@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * failure: None/Unknown => GHC accepts invalid program * component: Compiler => Compiler (Type checker) Comment: If I understand things correctly, the type checker should refuse to `print` a `(# Bool | Bool #)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 05:17:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 05:17:40 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.8de56476c4174a60ad67f6d3a2c36f7d@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) * failure: GHC accepts invalid program => None/Unknown * component: Compiler (Type checker) => Compiler Comment: The fact that the code in `Main` doesn't typecheck is unimportant, since you can also trigger the panic with this code that does typecheck: {{{#!hs -- Bug.hs {-# LANGUAGE UnboxedSums #-} module Main where import Testing main :: IO () main = print $ case func () of (# True | #) -> 123 _ -> 321 }}} cc'ing Ben, who wrote the `getUnboxedSumName` function in 34d933d6a821edf5abfcbee76d9325362fc28a13. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 06:29:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 06:29:06 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 Message-ID: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- I recently noticed that the performance of `doctest` in GHC 8.2.1 can be much, much worse than in previous versions of 8.0.2. So bad, in fact, that a project with 865 `doctest` examples takes about three hours to complete in 8.2.1, whereas it would only take 8 seconds in 8.0.2. To reproduce this issue in a fairly minimal way, you can use the following script to generate a file which simulates what `doctest` is doing: {{{#!hs -- GenExample.hs module Main where import Control.Monad import System.Environment import System.Exit import System.IO main :: IO () main = do args <- getArgs case args of n:_ -> genExamples (read n) _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs " exitWith $ ExitFailure 1 genExamples :: Int -> IO () genExamples nExamples = do putStrLn ":l Foo" ireplicateA_ nExamples genExample genExample :: Int -> IO () genExample i = putStr $ unlines [ ":m *Foo" , "example : \"expr" ++ show i ++ "\"" , "let foo = it" , "\"marker\"" , "let it = foo" ] ireplicateA_ :: Applicative m => Int -> (Int -> m a) -> m () ireplicateA_ cnt0 f = loop cnt0 0 where loop cnt n | cnt <= 0 = pure () | otherwise = f n *> (loop (cnt - 1) $! (n + 1)) }}} You'll also need this file: {{{#!hs -- Foo.hs module Foo where example :: Char example = 'a' }}} First, use `GenExample` to generate a GHCi script: {{{ $ runghc GenExample.hs 500 > Example.script }}} Now you can run the script like so (using GHCi 8.0.2 as an example): {{{ $ /opt/ghc/8.0.2/bin/ghci -ghci-script Example.script Foo.hs }}} With GHCi 8.0.2, this takes about three seconds. But with GHCi 8.2.1, this takes about 35 seconds! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 06:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 06:31:22 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.0435b59e50ed44ca5db72eddbff92461@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that in `GenExample`, the crucial bit is here: {{{#!hs genExample :: Int -> IO () genExample i = putStr $ unlines [ ":m *Foo" , "example : \"expr" ++ show i ++ "\"" , "let foo = it" , "\"marker\"" , "let it = foo" ] }}} Both the `:m *Foo` part, as well as `let foo = it`/`let it = foo`, are crucial to triggering the slowdown. If one of them is commented out, then GHCi 8.2.1 achieves parity in speed with 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 06:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 06:39:33 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.6e3e679dc8e659a46d8db887c98c4734@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I recently noticed that the performance of `doctest` in GHC 8.2.1 can be > much, much worse than in previous versions of 8.0.2. So bad, in fact, > that a project with 865 `doctest` examples takes about three hours to > complete in 8.2.1, whereas it would only take 8 seconds in 8.0.2. > > To reproduce this issue in a fairly minimal way, you can use the > following script to generate a file which simulates what `doctest` is > doing: > > {{{#!hs > -- GenExample.hs > module Main where > > import Control.Monad > > import System.Environment > import System.Exit > import System.IO > > main :: IO () > main = do > args <- getArgs > case args of > n:_ -> genExamples (read n) > _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs examples>" > exitWith $ ExitFailure 1 > > genExamples :: Int -> IO () > genExamples nExamples = do > putStrLn ":l Foo" > ireplicateA_ nExamples genExample > > genExample :: Int -> IO () > genExample i = putStr $ unlines > [ ":m *Foo" > , "example : \"expr" ++ show i ++ "\"" > , "let foo = it" > , "\"marker\"" > , "let it = foo" > ] > > ireplicateA_ :: Applicative m => Int -> (Int -> m a) -> m () > ireplicateA_ cnt0 f = > loop cnt0 0 > where > loop cnt n > | cnt <= 0 = pure () > | otherwise = f n *> (loop (cnt - 1) $! (n + 1)) > }}} > > You'll also need this file: > > {{{#!hs > -- Foo.hs > module Foo where > > example :: Char > example = 'a' > }}} > > First, use `GenExample` to generate a GHCi script: > > {{{ > $ runghc GenExample.hs 500 > Example.script > }}} > > Now you can run the script like so (using GHCi 8.0.2 as an example): > > {{{ > $ /opt/ghc/8.0.2/bin/ghci -ghci-script Example.script Foo.hs > }}} > > With GHCi 8.0.2, this takes about three seconds. But with GHCi 8.2.1, > this takes about 35 seconds! New description: I recently noticed that the performance of `doctest` in GHC 8.2.1 (see the corresponding [https://github.com/sol/doctest/issues/170 doctest issue]) can be much, much worse than in previous versions of 8.0.2. So bad, in fact, that a project with 865 `doctest` examples takes about three hours to complete in 8.2.1, whereas it would only take 8 seconds in 8.0.2. To reproduce this issue in a fairly minimal way, you can use the following script to generate a file which simulates what `doctest` is doing: {{{#!hs -- GenExample.hs module Main where import Control.Monad import System.Environment import System.Exit import System.IO main :: IO () main = do args <- getArgs case args of n:_ -> genExamples (read n) _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs " exitWith $ ExitFailure 1 genExamples :: Int -> IO () genExamples nExamples = do putStrLn ":l Foo" ireplicateA_ nExamples genExample genExample :: Int -> IO () genExample i = putStr $ unlines [ ":m *Foo" , "example : \"expr" ++ show i ++ "\"" , "let foo = it" , "\"marker\"" , "let it = foo" ] ireplicateA_ :: Applicative m => Int -> (Int -> m a) -> m () ireplicateA_ cnt0 f = loop cnt0 0 where loop cnt n | cnt <= 0 = pure () | otherwise = f n *> (loop (cnt - 1) $! (n + 1)) }}} You'll also need this file: {{{#!hs -- Foo.hs module Foo where example :: Char example = 'a' }}} First, use `GenExample` to generate a GHCi script: {{{ $ runghc GenExample.hs 500 > Example.script }}} Now you can run the script like so (using GHCi 8.0.2 as an example): {{{ $ /opt/ghc/8.0.2/bin/ghci -ghci-script Example.script Foo.hs }}} With GHCi 8.0.2, this takes about three seconds. But with GHCi 8.2.1, this takes about 35 seconds! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 08:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 08:30:25 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition Message-ID: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: | Owner: (none) SwiftsNamesake | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, | Operating System: Unknown/Multiple windows | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Preprocessing library Pixels-0.1.0.0... [1 of 9] Compiling Pixels.Walker ( src\Pixels\Walker.hs, .stack- work\dist\ca59d0ab\build\Pixels\Walker.o ) [2 of 9] Compiling Pixels.Types ( src\Pixels\Types.hs, .stack- work\dist\ca59d0ab\build\Pixels\Types.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol runInteractiveProcess whilst processing object file C:\Users\Jonatan\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\process-1.4.3.0\HSprocess-1.4.3.0.o The symbol was previously defined in C:\sr\snapshots\55a68d16\lib\x86_64-windows- ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\HSprocess-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Jonatan\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.0.2\\lib\\process-1.4.3.0\\HSprocess-1.4.3.0.o": failed CallStack (from HasCallStack): error, called at libraries\ghci\GHCi\ObjLink.hs:97:21 in ghci-8.0.2:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} OS: Windows 10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 10:15:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 10:15:53 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.139e6f7725efd0251a5e26f4f7e0d58d@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): > GHC rejects the following instance, complaining about the use of a type synonym family in the instance head ... ? This isn't a bug. GHC has never allowed type family applications in the instance head. (With FlexibleInstances, it does allow type synonyms.) #3485 is an enhancement request (and closed, for good reasons IMO). So the FunctionalDependency is a red herring. I agree with your suggestion on lens#754 the Template Haskell for lenses should be smarter. If there's an opportunity for an enhancement, I think there's a more general suggestion. Borrow the irrefutable patterns idea like: {{{ instance HasValue (Rec a) ~(Fam a) where ... }}} And allow `~( ... )` to be any type or family application. Treat it as syntactic sugar for: {{{ instance (b0 ~ Fam a) => HasValue (Rec a) b0 where ... -- b0 is fresh }}} Also there's an opportunity for the compiler to see that instance (as compared with others): a. doesn't really overlap b. is consistent with FunDeps c. doesn't break the Coverage Condition -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 11:35:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 11:35:48 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.399616a011d29bf12c4bf3a36875eebc@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): My libuv branch finally start to run! For now i only test it with concurrent tcp clients, judged by running time, eventlog and `RTS -s` report, i'm pretty sure its performance is on pair with the old IO manager, Now i'm try to bring a tcp server benchmark, let's see how fast it is going to be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:01:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:01:11 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.72a142443634516d456817bf6d946557@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This may be fixed by #12919, which I plan to tackle in the next few days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:04:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:04:57 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.6fef826addf4826839dfcea34664ffcf@haskell.org> #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I looked at T13594, which is another assertion failure. It has code like {{{#!hs blah :: ... !blah = ... }}} at the top level. The ticket (#13594) and test case suggest that the code should be accepted. But I disagree -- so I think the fix for that ticket is bogus. Other thoughts? T13822 may be #12919 in disguise, but I'm not quite sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:06:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:06:48 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.361b8ac0042bcfa0d4d281c0ce59f40e@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: fixed | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Furthermore, I thought top-level bangs were disallowed, regardless of types. The existence of a top-level bang causes an assertion failure in a debug compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:42:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:42:55 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.73668e346a649c2a923e27ca1cb5bb66@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 goldfire): I'm very confused here. I think this is much simpler than we're making it out to be. `newName` is a facility for creating a name distinct from all others. As I've always understood it, the parameter given to `newName` is simply a hint, so that printing out the names are legible to a human. It should ''not'' be an integral part of its behavior. A corollary of the above definition is that it should be impossible to write the result of a `newName` outside of TH. Thus comment:9 is a non- issue. As it turns out, the renamer doesn't always respect the opaqueness of `newName`s (for example, in fixity declarations). This should be fixed. Perhaps there are other bugs, too. But when all is well, `newName` should work fine for local and top-level definitions. You naturally can't export `newName`s, because you can't write them in an export list. (And we would make sure they're not exported if there is no export list.) And, I think, that's it. Is there something I'm missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:47:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:47:48 -0000 Subject: [GHC] #14042: Misleading error message when type family is used in datatype's return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.240374871053f616666675fc602b7983@haskell.org> #14042: Misleading error message when type family is used in datatype's return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- Comment (by goldfire): What would you like the error message to say? It looks correct to me. Perhaps it could have an "NB: no type functions" or something, but it's not too far off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 13:49:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 13:49:07 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.2c1aac38623db17002bbf7fa6070b285@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Hmm looks like I also discovered that `fdReady()` doesn't work at all on Windows for the `case FILE_TYPE_PIPE`. This example file {{{ import System.IO main = hWaitForInput stdin (5 * 1000) }}} when compiled with `ghc --make -O -fforce-recomp ../example-windows- pipe.hs && time ../example-windows-pipe.hs` terminates immediately instead of waiting for 5 seconds. The reason seems to be that the `PeekNamedPipe( hFile, NULL, 0, NULL, &avail, NULL )`, which is called only once in `fdReady()`, doesn't have any blocking feature. From the docs https://msdn.microsoft.com/en- us/library/windows/desktop/aa365779(v=vs.85).aspx > The function always returns immediately in a single-threaded application, even if there is no data in the pipe (Not sure why it says "in a single-threaded application"; the same problem happens with `-threaded` and `+RTS -N2`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:18:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:18:14 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.956c922addc99b2038085b95b5782493@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * owner: (none) => bgamari * milestone: => 8.2.2 Comment: Thanks for the report! I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm In-Reply-To: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> References: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> Message-ID: <061.aa8894062c478e1d0d6572197014e1a9@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3787 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e3c10160472df082fd3decd98c2489a2f8e68bd/ghc" 0e3c1016/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e3c10160472df082fd3decd98c2489a2f8e68bd" Ensure that we always link against libm ld.gold is particularly picky that we declare all of our link dependencies on Nix. See #14022. Test Plan: Validate on Nix Reviewers: austin Subscribers: hvr, rwbarton, thomie GHC Trac Issues: #14022 Differential Revision: https://phabricator.haskell.org/D3787 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #14050: GHC HEAD test suite is broken with Python 3.4.3 In-Reply-To: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> References: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> Message-ID: <065.59a54bf736d1f434eafdeb6217146445@haskell.org> #14050: GHC HEAD test suite is broken with Python 3.4.3 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3803 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e3eacc7191593ca61992b044a3875dbb50903e6/ghc" 0e3eacc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e3eacc7191593ca61992b044a3875dbb50903e6" testsuite: Don't pass allow_abbrev This is only supported by Python 3.5 and later, which is too new for us to rely on. Reviewers: austin Subscribers: rwbarton, thomie, RyanGlScott GHC Trac Issues: #14050 Differential Revision: https://phabricator.haskell.org/D3803 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #5252: UNPACK without optimisation leads to panic In-Reply-To: <046.197b10301a44159175d2cccd7c28dcbc@haskell.org> References: <046.197b10301a44159175d2cccd7c28dcbc@haskell.org> Message-ID: <061.11f42ddf21476ac07756fde1cb14cd32@haskell.org> #5252: UNPACK without optimisation leads to panic -------------------------+------------------------------------------------- Reporter: | Owner: (none) simonpj | Type: bug | Status: closed Priority: | Milestone: 7.6.2 normal | Component: | Version: 7.6.1 Compiler | Resolution: | Keywords: fixed | Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: deSugar/should_compile/T5252, None/Unknown | T5252Take2 Blocked By: | Blocking: Related Tickets: | -------------------------+------------------------------------------------- Comment (by Ben Gamari ): In [changeset:"121fee99496d5f5d53a8cd6b08c13a0b6bb9069d/ghc" 121fee99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="121fee99496d5f5d53a8cd6b08c13a0b6bb9069d" Remove unnecessary GHC option from SrcLoc This was an old workaround for #5252. Fixes #13173. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3763 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.94f90a0a6e84d80f0cac31467260b1a7@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d75bba852db208b1d9fcb84dab01598a765d2534/ghc" d75bba8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d75bba852db208b1d9fcb84dab01598a765d2534" Add rtsopts ignore and ignoreAll. These ignore commandline arguments for ignore and commandline as well as GHCRTS arguments for ignoreAll. Passing RTS flags given on the command line along to the program by simply skipping processing of these flags by the RTS. This fixes #12870. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #12870 Differential Revision: https://phabricator.haskell.org/D3740 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.5720bfaada99ae3cb3dcf7740df435ad@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: hs-boot 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): Phab:D3743 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9e9fb57c37c62bb6c90f15b173c5d3632121c66a/ghc" 9e9fb57/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e9fb57c37c62bb6c90f15b173c5d3632121c66a" Fix hs-boot knot-tying with record wild cards. Fixes #13710. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13710 Differential Revision: https://phabricator.haskell.org/D3743 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.f5154853a84ec8faadabaada9e6395c4@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9cfabbb5267e72b8017d8dc04d8580f73f425aa8/ghc" 9cfabbb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cfabbb5267e72b8017d8dc04d8580f73f425aa8" Add '<&>' operator to Data.Functor. '<&>' calls '<$>' with flipped arguments. This was proposed by David Feuer (https://mail.haskell.org/pipermail/libraries/2016-August/027293.html) and solves #14029. The implementation is a copy of the '<&>' operator in Control.Lens.Lens. Add tests for following Data.Functor operators: '<$>', '<&>', '<$' and '$>'. '<&>' was added for solving #14029. '<$>', '<$' and '$>' were probably untested. Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3800 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.e1877f6d3cd8430f3d469ed69f466d52@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3763 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"121fee99496d5f5d53a8cd6b08c13a0b6bb9069d/ghc" 121fee99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="121fee99496d5f5d53a8cd6b08c13a0b6bb9069d" Remove unnecessary GHC option from SrcLoc This was an old workaround for #5252. Fixes #13173. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3763 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 14:34:24 -0000 Subject: [GHC] #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? In-Reply-To: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> References: <044.2a345a79958931c78613a0f2e2c31ac2@haskell.org> Message-ID: <059.a7c241d55229ced63ac3e178feab6f22@haskell.org> #14028: ghc panic: -fexternal-interpreter + .o + QuasiQuotes? -------------------------------------+------------------------------------- Reporter: blynn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: ghc panic | impossible Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T14028 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"84f8e86248d47f619a94c68260876a1258e0a931/ghc" 84f8e86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="84f8e86248d47f619a94c68260876a1258e0a931" Ensure that GHC.Stack.callStack doesn't fail Test Plan: Validate, ensure the `f7` program of `IPLocation` doesn't crash. Reviewers: gridaphobe, austin, hvr Reviewed By: gridaphobe Subscribers: rwbarton, thomie GHC Trac Issues: #14028 Differential Revision: https://phabricator.haskell.org/D3795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:22:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:22:47 -0000 Subject: [GHC] #14042: Misleading error message when type family is used in datatype's return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.e8ae201c1f6eebda1b49fc35d585ed9b@haskell.org> #14042: Misleading error message when type family is used in datatype's return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Just like type families are rejected in class instances: {{{ > :set -XTypeFamilies > type family Foo a > instance Show (Foo a) :4:10: error: * Illegal type synonym family application in instance: Foo a * In the instance declaration for `Show (Foo a)' }}} I want the error message for type families in data type return kinds to be similarly informative. Something like: {{{ > data Foo :: Id Type * Illegal type synonym family application in return kind of data type declaration Id Type }}} None of this faffery about non-`*` return kinds, since that's not the real issue here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:24:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:24:08 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.de28000173fc28bc44137f0fa84078e0@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): Hm. Provided there's a robust way to comprehensively rule out //all// occurrences of duplicate names with different uniques, I think I could support this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:28:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:28:20 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.73a1ced355d574390e41c72e99787da6@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: Where can we find the code this is from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:31:37 -0000 Subject: [GHC] #14054: Cabal generates ill-typed Paths module when relocatable Message-ID: <045.4319866d264e103497bc03abff674a19@haskell.org> #14054: Cabal generates ill-typed Paths module when relocatable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Keywords: Cabal | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A PR has been submitted https://github.com/haskell/cabal/pull/4638 and we know this bug affects the Cabal fixed with GHC. When we do 8.2.2 we should make sure we get a fixed version of Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:32:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:32:14 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.cbf0bbd35d3c2c32e7453b29f165461a@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d1ef223cfebd23c25489a4b0c67fbaa2f91c1ec6/ghc" d1ef223c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1ef223cfebd23c25489a4b0c67fbaa2f91c1ec6" Fix #14045 by omitting an unnecessary check Previously, we checked the number of patterns in a data instances for all data families whose kind did not end in a kind variable. But, of course, undersaturating instances can happen even without the kind ending in a kind variable. So I've omitted the arity check. Data families aren't as particular about their arity as type families are (because data families can be undersaturated). Still, this change degrades error messages when instances don't have the right arity; now, instead of reporting a simple mismatch in the number of patterns, GHC reports kind errors. The new errors are fully accurate, but perhaps not as easy to work with. Still, with the new flexibility of allowing data family instances with varying numbers of patterns, I don't see a better way. This commit also improves source fidelity in some error messages, requiring more changes than really are necessary. But without these changes, error messages around mismatched associated instance heads were poor. test cases: indexed-types/should_compile/T14045, indexed-types/should_fail/T14045a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:33:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:33:17 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.558e3a8f173c5a7b3924c2a4cd64d1ea@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_compile/T14045, indexed- types/should_fail/T14045a * resolution: => fixed Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:38:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:38:44 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.4e6162d6f87b3589df92bd4ed467cfae@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows 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: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): It's one of my own projects. I suppose I could put it up on GitHub. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:44:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:44:57 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.bd3668bc76ce9e72f19ffd998a3a35b7@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Please do! There's not much we can do to diagnose the issue unless we have something to work with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:46:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:46:40 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.90f0aa4ed90da2036246deccfe43f717@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows 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: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): I'm using stack if that's any help. I'll upload the project when I have time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:48:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:48:49 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.df76c77a21f072fb8e66255aefc94150@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by SwiftsNamesake): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 15:52:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 15:52:51 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.1bd335b4e46b07307cc4a947216d3346@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): OS is Windows 10, by the way. Tried to edit the report, but that was rejected as spam for some inscrutable reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 16:01:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 16:01:52 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.71c9939e5a11807354d6b6cbfd376985@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I think info about this should at least be added to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/FreeBSD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 16:14:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 16:14:23 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.a808a01e4c851a4f2f2b91818fa99bde@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I have pushed a set of [[https://www.haskell.org/ghc/download_ghc_8_2_1.html#openbsd_61_x86_64|OpenBSD 6.1 bindists]]. Let me know if they resolve your issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 17:05:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 17:05:52 -0000 Subject: [GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces In-Reply-To: <050.88678544262d43e8177c20f56750d292@haskell.org> References: <050.88678544262d43e8177c20f56750d292@haskell.org> Message-ID: <065.fc51f15f057770c5f6e175f89b029281@haskell.org> #14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 RyanGlScott): I've submitted a proposal at https://github.com/ghc-proposals/ghc- proposals/pull/65. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 18:38:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 18:38:27 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.5608f6a756393f7bf9d0843f53b6cae6@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mniip (added) * milestone: => 8.4.1 Comment: Commit 59d7ee53906b9cee7f279c1f9567af7b930f8636 (`GHCi: Don't remove shadowed bindings from typechecker scope.`) caused this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 18:43:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 18:43:07 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.9f5178b5e8c875bf5fb34004cbf2497f@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To make things worse, this script takes even longer between GHC 8.2.1 and HEAD. As noted above, on 8.2.1 it takes about 35 seconds, but on GHC HEAD (as of commit d08b9ccdf2812e8f8fa34d0c89275deee574524c), it takes about 2 minutes 32 seconds. I still need to investigate to which commit(s) were responsible for this further regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 18:50:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 18:50:53 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.e0d4d39600bed45c5af7f4ef37981d70@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 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 patrickdoc): I have a proof of concept for this. It's looking like the best plan is to wrap the table info into the declaration of a flag, something like: {{{ .. ghc-flag:: -v :shortdesc: verbose mode (equivalent to -v3) :type: dynamic :reverse: (none for this flag) Longer decription here... }}} Which would render as: **-v** Longer description here and then the table could look like, | **-v** | verbose mode (equivalent to -v3) | dynamic | | --- The main tasks remaining are figuring out the formatting of the table, determining what variables actually need to be passed around, and moving all the info into the flag declarations from the `mkUserGuidePart` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 19:34:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 19:34:14 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.4bb054891c249e8d19fc274271b602e3@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): Ben, thank you. The new ghc-8.2.1 bindist for OpenBSD 6.1 works now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 19:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 19:35:17 -0000 Subject: [GHC] #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 In-Reply-To: <053.b99b243583300981f24cb199e196b0b4@haskell.org> References: <053.b99b243583300981f24cb199e196b0b4@haskell.org> Message-ID: <068.71b0785903eb933e2cfd82ed5c877d4c@haskell.org> #14041: ghc-8.2.1 installation fails on OpenBSD 6.1 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by romanzolotarev): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 20:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 20:16:54 -0000 Subject: [GHC] #14055: Panic on type error inside a type-level newtype (with -XTypeInType) Message-ID: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> #14055: Panic on type error inside a type-level newtype (with -XTypeInType) -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies #-} newtype X = RollX (() -> X) type family F t :: X where F t = RollX (t -> ()) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys t_a1po[sk:1] () [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 20:18:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 20:18:13 -0000 Subject: [GHC] #14055: Panic on type error inside a type-level newtype (was: Panic on type error inside a type-level newtype (with -XTypeInType)) In-Reply-To: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> References: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> Message-ID: <059.83914a87228f47805d78cb1d57101f59@haskell.org> #14055: Panic on type error inside a type-level newtype -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by luqui: Old description: > {{{#!hs > {-# LANGUAGE TypeInType, TypeFamilies #-} > > newtype X = RollX (() -> X) > > type family F t :: X where > F t = RollX (t -> ()) > }}} > > gives > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.1 for x86_64-apple-darwin): > repSplitAppTys > t_a1po[sk:1] > () > [] > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type > }}} New description: {{{#!hs {-# LANGUAGE DataKinds, TypeFamilies #-} newtype X = RollX (() -> X) type family F t :: X where F t = RollX (t -> ()) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys t_a1po[sk:1] () [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:23:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:23:48 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.5bd1eeb4bd15a10e7acfc1ce6a45e101@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: patrickdoc Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.3 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 bgamari): Yay, thank you patrickdoc! Indeed that flag definition is exactly what I had in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:28:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:28:07 -0000 Subject: [GHC] #13710: panic with boot and -jX In-Reply-To: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> References: <044.0eeac669ba8b5eeee057a55613b1dd46@haskell.org> Message-ID: <059.d8d46d15b309d0e273707344590c0454@haskell.org> #13710: panic with boot and -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: hs-boot 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): Phab:D3743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:28:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:28:46 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.40e20484793949022ebeba22a62fd923@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:30:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:30:33 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc In-Reply-To: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> References: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> Message-ID: <064.808ab1d6eae95e09e685bfc5fed2d3c5@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: supersven Type: task | Status: closed Priority: lowest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Old description: > There is a comment at the top of `SrcLoc` which says > > {{{ > {-# OPTIONS_GHC -fno-omit-interface-pragmas #-} > -- Workaround for Trac #5252 crashes the bootstrap compiler without -O > -- When the earliest compiler we want to boostrap with is > -- GHC 7.2, we can make RealSrcLoc properly abstract > }}} > > This is a well-defined small task so I will mark it for newcomers. > > 1. Try to work out what the pragma is meant to do by reading #5252 > 2. Work out whether we can now make `RealSrcLoc` "properly abstract" (if > it is not already) > 3. Remove or update this comment and pragma. > 4. Pray it doesn't break the whole compiler. New description: There is a comment at the top of `SrcLoc` which says {{{#!hs {-# OPTIONS_GHC -fno-omit-interface-pragmas #-} -- Workaround for Trac #5252 crashes the bootstrap compiler without -O -- When the earliest compiler we want to boostrap with is -- GHC 7.2, we can make RealSrcLoc properly abstract }}} This is a well-defined small task so I will mark it for newcomers. 1. Try to work out what the pragma is meant to do by reading #5252 2. Work out whether we can now make `RealSrcLoc` "properly abstract" (if it is not already) 3. Remove or update this comment and pragma. 4. Pray it doesn't break the whole compiler. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:31:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:31:06 -0000 Subject: [GHC] #14050: GHC HEAD test suite is broken with Python 3.4.3 In-Reply-To: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> References: <050.81aaebcbfa3bccc491f899d7eeb549a0@haskell.org> Message-ID: <065.ba7791f78fbc862d13dcb2317405c4c1@haskell.org> #14050: GHC HEAD test suite is broken with Python 3.4.3 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3803 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Sorry about that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:31:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:31:47 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.1d1da09d6deae30a7242a532d9ccf277@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:50:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:50:05 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.de9d6e3d1762d6c5af95ddb14fbc3b7c@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): **An update for GHC 8.2:** GHC 8.2 has improved on this problem for POSIX platforms, two-fold: 1. GHC 8.2 has fixed the crashing problem of `fdReady()` that was introduced in GHC 8.0.2 (but not present in 8.0.1), that I mentioned in Comment 2 further above. 2. That fix (commit [http://github.com/ghc/ghc/commit/ae69eaed6e2a5dff7f3a61d4373b7c52e715e3ad ae69eaed] - "base: Fix hWaitForInput with timeout on POSIX") works by repeatedly inspecting the current time (because `select()` is gone and was replaced by `poll()` in commit [http://github.com/ghc/ghc/commit/f46369b8a1bf90a3bdc30f2b566c3a7e03672518 f46369b8], which doesn't have the functionality of advancing a timeout pointer even on Linux), so the problem that was described in the original issue description is gone for FreeBSD / OSX / any platform that's not Windows. However, there are remaining problems with the current in implementation: * It currently uses `gettimeofday()`, which doesn't use a monotonic clock, so any time adjustment can make `fdReady()` wait for significantly more or less than it should. * It keeps track of the total time waited by adding up time differences between calls to `gettimeofday()`: {{{ while ((res = poll(fds, 1, msecs)) < 0) { if (errno == EINTR) { if (msecs > 0) { struct timeval tv; if (gettimeofday(&tv, NULL) != 0) { fprintf(stderr, "fdReady: gettimeofday failed: %s\n", strerror(errno)); abort(); } int elapsed = 1000 * (tv.tv_sec - tv0.tv_sec) + (tv.tv_usec - tv0.tv_usec) / 1000; msecs -= elapsed; if (msecs <= 0) return 0; tv0 = tv; } } else { return (-1); } } }}} This is inaccurate, because the code between `gettimeofday()` and `tv0 = tv;` is not tracked. If the process is descheduled by the OS in these lines, then that time is "lost" and `fdReady()` will wait way too long. This inacurracy can easily be observed and magnified by increasing the frequency of signals arriving at the program. Consider this simple program `ghc-bug-13497-accuracy-test.hs` that waits 5 seconds for input on stdin: {{{ import System.IO main = hWaitForInput stdin (5 * 1000) }}} When run normally on GHC 8.2.1 (release commit 0cee25253), this program terminates within 5 seconds when run with the command line {{{ inplace/bin/ghc-stage2 --make -fforce-recomp -rtsopts ghc-bug-13497 -accuracy-test.hs /usr/bin/time ./ghc-bug-13497-accuracy-test }}} But it starts taking much longer when `+RTS -V...` is added for increasingly frequent values of `-V`; the effect is even stronger when setting the idle GC timer to something large (e.g. `-I10` for every 10 seconds): {{{ no `-V` passed 0.00user 0.00system 0:05.02elapsed 0%CPU -V0.1 0.00user 0.00system 0:05.01elapsed 0%CPU -V0.01 0.00user 0.00system 0:05.01elapsed 0%CPU -V0.001 0.00user 0.00system 0:05.13elapsed 0%CPU -V0.0001 0.00user 0.00system 0:05.30elapsed 0%CPU -V0.00001 0.06user 0.00system 0:05.31elapsed 1%CPU -V0.000001 0.37user 0.20system 0:05.73elapsed 10%CPU -V0.0000001 2.67user 3.30system 0:12.47elapsed 47%CPU -V0.00000001 50.44user 7.32system 1:17.50elapsed 74%CPU -I10 -V0.1 0.00user 0.00system 0:05.10elapsed 0%CPU -I10 -V0.01 0.00user 0.00system 0:05.25elapsed 0%CPU -I10 -V0.001 0.00user 0.10system 0:08.47elapsed 1%CPU -I10 -V0.0001 the program did not terminate within 2 minutes of waiting }}} It reason it's worse with `-I10` is that, as described above, without `-I` ghc stops the timer signal after 0.3 seconds (so no `EINTR`s are occurring beyond that time), and with `-I` given it doesn't. Not all of the above is in the non-threaded runtime. Doing the same with `-threaded` on Linux gives reliable `0.00user 0.00system 0:05.01elapsed 0%CPU` no matter what `-V` or `-I` is passed, and `strace` shows that there are no `EINTR`s happening in that case. I suspect this is because `hWaitForInput` calls `fdReady()` as a `safe` foreign call, which makes it have its own thread in the threaded runtime. There is also an `unsafe` call to `fdReady()` but that one is only used with timeouts of `0` so that's not a problem. On FreeBSD 11, non-threaded, the situation is worse: {{{ no `-V` passed 5.14 real 0.00 user 0.00 sys -V0.1 5.10 real 0.00 user 0.00 sys -V0.01 5.16 real 0.00 user 0.00 sys -V0.001 5.17 real 0.00 user 0.02 sys -V0.0001 5.24 real 0.00 user 0.01 sys -V0.00001 5.89 real 0.01 user 0.08 sys -V0.000001 5.81 real 0.00 user 0.11 sys -V0.0000001 6.05 real 0.00 user 0.09 sys -V0.00000001 5.77 real 0.00 user 0.09 sys -I10 -V0.1 5.13 real 0.00 user 0.01 sys -I10 -V0.01 5.24 real 0.00 user 0.01 sys -I10 -V0.001 5.90 real 0.00 user 0.10 sys -I10 -V0.0001 5.82 real 0.00 user 0.09 sys }}} And with `-threaded` on FreeBSD 11: {{{ no `-V` passed 5.15 real 0.00 user 0.01 sys -V0.1 5.30 real 0.00 user 0.00 sys -V0.01 5.31 real 0.00 user 0.01 sys -V0.001 5.45 real 0.00 user 0.13 sys -V0.0001 5.98 real 0.00 user 0.13 sys -V0.00001 5.93 real 0.00 user 0.15 sys -V0.000001 5.79 real 0.00 user 0.15 sys -V0.0000001 5.83 real 0.00 user 0.13 sys -V0.00000001 5.80 real 0.00 user 0.18 sys -I10 -V0.1 5.13 real 0.00 user 0.01 sys -I10 -V0.01 5.27 real 0.00 user 0.03 sys -I10 -V0.001 5.77 real 0.00 user 0.12 sys -I10 -V0.0001 5.90 real 0.00 user 0.18 sys }}} As you can see, on FreeBSD 11 the `-threaded` doesn't fix the issues as it does on Linux, and `truss` suggests that that is because `EINTR`s arrive (while they didn't on Linux). I'm not sure why with `threaded` on FreeBSD there's `EINTR`s happening but not on Linux, but I observed that on Linux we have instead: {{{ [pid 30502] timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC) = 7 ... [pid 30502] read(7, "\1\0\0\0\0\0\0\0", 8) = 8 [pid 30502] read(7, "\1\0\0\0\0\0\0\0", 8) = 8 [pid 30502] read(7, "\1\0\0\0\0\0\0\0", 8) = 8 [pid 30502] read(7, "\1\0\0\0\0\0\0\0", 8) = 8 ... }}} So I suspect that the difference is that Linux has `timerfd` and FreeBSD doesn't. ---- OK, so far the problem description. **The summary is:** * In the nonthreaded runtime, a high precision `-V` destroys accuracy * On non-Linux (systems without `timerfd`), this happens even with `-threaded` * In any runtime, accuracy can be screwed with due to non-use of monotonic clocks. **The fix** is simple: Use the monotonic clock, and instead of tracking waited time as a sum of wait intervals, always compare the current time with the _end_ time (time at entry of `fdReady()` + `msec`). I have implemented this in commit [https://github.com/nh2/ghc/commit/12f9d66b5c837c221be080b526dcb61fecb7cf1c 12f9d66b] of my branch [https://github.com/ghc/ghc/compare/ghc-8.2.1-release...nh2:ghc-8.2.1 -improve-fdRready-precision ghc-8.2.1-improve-fdRready-precision] (the first link is stable, the latter may change as I write more fixes for Windows). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:51:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:51:39 -0000 Subject: [GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513 In-Reply-To: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> References: <050.26c090b23f043a27e97c34a15d948c31@haskell.org> Message-ID: <065.0c921003dfc2c7c5bd25f2d3fa9ae61f@haskell.org> #14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3805 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:53:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:53:34 -0000 Subject: [GHC] #14022: base and ghc-prim should depend upon libm In-Reply-To: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> References: <046.17a5b4d18673698e009237f3dc65c661@haskell.org> Message-ID: <061.40c946a7ac1a4ca7fc7e45a40908c74f@haskell.org> #14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3787 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 22:54:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 22:54:40 -0000 Subject: [GHC] #14029: Implement the "Add <&> to Data.Functor" proposal In-Reply-To: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> References: <050.ee4afdfbde4f8cf54be6f7813deee4e7@haskell.org> Message-ID: <065.8d8a452f5737432f4e571f737e25eb00@haskell.org> #14029: Implement the "Add <&> to Data.Functor" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: supersven Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 23:01:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 23:01:09 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.9e5e1477055a9d4c22c9a76896cfff0d@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): With my fix, I reliably get, independent of `-threaded` or not, on Linux: {{{ 0:05.00elapsed }}} And on FreeBSD 11: {{{ 5.00 real }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 23:07:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 23:07:21 -0000 Subject: [GHC] #14056: Figure out what to do about libffi Message-ID: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> #14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- For some platform GHC depends upon `libffi` for foreign call support in the bytecode interpreter. Unfortunately `libffi`'s upstream seems to be unresponsive and there has not been a release in nearly three years. This means that there is currently no release which has, e.g., support for AArch64 and iOS's compact debug information. While we obviously want to avoid shipping our own patched libffi, at this point we are starting to run out of options. Consider options for resolving this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 23:11:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 23:11:53 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches Message-ID: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> #14057: Upstream Alpine Linux distribution patches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- Alpine Linux has a variety of [[https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable|patches]] to allow GHC to build against the musl libc implementation. Let's get these upstream. Here is my take on the patches: * `0000-alpine.patch`: This is a no-brainer. Will gladly accept. * `0000-bootstrap.patch`: I really don't know about this one. The motivation is quite unclear. Needs discussion. * `0001-rm-ghc-pwd.patch`: Already merged in 4c56ad36ee0d1f8b6f1b2bc0d8fff1c9acd1a389. * `0002-Correct-issue-with-libffi-and-glibc.patch`: This is, unfortunately, a `libffi` fix, not a GHC fix. I'm not enthusiastic about patching libffi like this. However, `libffi`'s upstream is quite unresponsive and we are waiting for them to act on a number of issues, so perhaps we'll need to reconsider this. I've created #14056 to track this. * `0003-do-not-use-SHELL.patch`: Looks reasonable to me. * `0004-reproducible-tmp-names.patch`: Seems plausible. * `0005-buildpath-abi-stability.patch`: There's some discussion in #10424. * `0006-fix-madvise.patch`: Merged in 6576bf83cdf4eac05eb88a24aa934a736c91e3da. See #12865 * `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 23:22:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 23:22:36 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.35e4d4b3fe3c5372b57ee5fb19777394@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * blockedby: 13525 => 13497, 13525 Comment: Marking this as blocked by #13497 because that one is about getting the timing of `fdReady()` right. I believe that should be completed before making sure `fdReady()` can be interrupted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 29 23:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Jul 2017 23:33:05 -0000 Subject: [GHC] #14055: Panic on type error inside a type-level newtype In-Reply-To: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> References: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> Message-ID: <059.cdd0276c2efa0a0224c57b235e5c9f9d@haskell.org> #14055: Panic on type error inside a type-level newtype -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) * architecture: x86_64 (amd64) => Unknown/Multiple Comment: This doesn't panic on GHC HEAD: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170729: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:6:18: error: • Expected kind ‘() -> X’, but ‘t -> ()’ has kind ‘*’ • In the first argument of ‘RollX’, namely ‘(t -> ())’ In the type ‘RollX (t -> ())’ In the type family declaration for ‘F’ | 6 | F t = RollX (t -> ()) | ^^^^^^^ }}} 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 likely fixed this. I'll add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 00:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 00:04:08 -0000 Subject: [GHC] #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations In-Reply-To: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> References: <050.e6ef0eaaad5555a490c4013a48ebaae7@haskell.org> Message-ID: <065.8f18c1d9154d9da464bb5417ee5522a7@haskell.org> #13887: Template Haskell pretty-printer doesn't parenthesize infix datatype names in data declarations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3717, Wiki Page: | Phab:D3802 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"7089dc2f12f9616771fc1de143e9b974157405d8/ghc" 7089dc2f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7089dc2f12f9616771fc1de143e9b974157405d8" Follow-up to #13887, for promoted infix constructors Summary: Correct a couple more spots in the TH pretty-printer by applying the appropriate parenthesization for infix names. Fixes #13887 (again). Test Plan: make test TEST=T13887 Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13887 Differential Revision: https://phabricator.haskell.org/D3802 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 00:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 00:04:08 -0000 Subject: [GHC] #14055: Panic on type error inside a type-level newtype In-Reply-To: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> References: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> Message-ID: <059.3542117ffc0be8ebbcb5c7079a97785c@haskell.org> #14055: Panic on type error inside a type-level newtype -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f839b9de18a9f795e438314bea9f17e594afa354/ghc" f839b9de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f839b9de18a9f795e438314bea9f17e594afa354" Add regression test for #14055 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 00:05:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 00:05:57 -0000 Subject: [GHC] #14055: Panic on type error inside a type-level newtype In-Reply-To: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> References: <044.77ffc8c0947c9d78ea40c06ae599bdf6@haskell.org> Message-ID: <059.64b49c9fd54a9b860474d9c91c04cc94@haskell.org> #14055: Panic on type error inside a type-level newtype -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T14055 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T14055 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 01:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 01:24:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.2aa95e4bb51e1f94b1673dc5d5b3bbd0@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lexi.lambda): * type: bug => feature request Comment: You’re right in that this isn’t really a bug, so I’ve changed it to a feature request. In that framing, I’m still not completely sure why this wouldn’t be a reasonable change. The coverage condition itself is precedent for weakening of restrictions in the presence of fundeps (in that case, instance decidability), and this does not seem meaningfully different to me. I could be convinced by an example of the sort that SPJ alluded to, in which an instance of the form `Multi X (Y a)` behaves differently from `(b ~ Y a) => Multi X b`, but I’m not sure sure what such an example would look like or how it would differ from a user’s point of view. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 01:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 01:53:08 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.9490ec4006579cae74c2b592a8041ffe@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Let me first throw some ideas out there to see if this even makes sense: Some data types have a related type class, for example `TypeRep` & `Typeable`, `Sing` & `SingI` {{{#!hs TypeRep :: k -> Type Typeable :: k -> Constraint Sing :: k -> Type SingI :: k -> Constraint }}} and classes that work for types as well as constructors {{{#!hs Eq :: Type -> Constraint Eq1 :: (Type -> Type) -> Constraint Eq2 :: (Type -> Type -> Type) -> Constraint }}} ---- It could completely re-use the syntax of type classes {{{#!hs data family Sing (a :: k) :: k' data instance Sing (a :: Bool) where SFalse :: Sing False STrue :: Sing True -- creates a class of kind `Sing :: k -> Constraint' class Sing (a :: k) where sing :: Sing a instance Sing (False :: Bool) where sing :: Sing (False :: Bool) sing = SFalse instance Sing (True :: Bool) where sing :: Sing (True :: Bool) sing = STrue }}} This lets us unify many names, {{{#!hs data family (,) :: k -> k -> k -- (,) :: Type -> Type -> Type data instance (a, b) = (a, b) -- (,) :: (k -> Type) -> (k -> Type) -> (k -> Type) data instance (f, g) a = Pair (f a) (g a) -- (,) :: (k -> k' -> Type) -> (k -> k' -> Type) -> (k -> k' -> Type) data instance (f, g) a b = Pair (f a b) (g a b) -- (,) :: Constraint -> Constraint -> Constraint class (a, b) => (a, b) instance (a, b) => (a, b) -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) class (f a, g a) => (f, g) a instance (f a, g a) => (f, g) a }}} if you don't see a problem with this I can submit a proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 02:21:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 02:21:38 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.57b5fa35e18793260d5f6a9b2103410f@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Random thoughts, we can derive `MonadReader Bool` {{{#!hs newtype A a = A (Bool -> a) deriving newtype (Functor, Applicative, Monad, MonadReader Bool) }}} but given an instance like `instance (Representable f, Rep f ~ a) => MonadReader a (Co f)`.. if we ever want to (non-standalone) derive that we cannot specify the context.. and if we can [https://www.reddit.com/r/haskell/comments/6ksr76/rfc_part_1_deriving_instances_of/ derive via newtypes] the `~(Rep f)` notation makes sense to have: {{{#!hs newtype B f a = B (f a) deriving newtype (Functor, Applicative, Monad) deriving via Co (B r) (MonadReader ~(Rep r)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 03:30:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 03:30:02 -0000 Subject: [GHC] #14056: Figure out what to do about libffi In-Reply-To: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> References: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> Message-ID: <061.9cfef1bfa4dcc082afef586eac099a0b@haskell.org> #14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 angerman): I really wonder how other languages that e.g. depend on the go support that was added after the last release handle this? Do they just depend on some repository hash? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 04:46:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 04:46:57 -0000 Subject: [GHC] #14058: Cannot bundle pattern synonym with exported data family Message-ID: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> #14058: Cannot bundle pattern synonym with exported data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd like to write this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo (Sing(.., SCons)) where data family Sing (a :: k) data instance Sing (z :: [a]) where SNil :: Sing '[] (:%) :: Sing x -> Sing xs -> Sing (x:xs) pattern SCons :: forall a (z :: [a]). () => forall (x :: a) (xs :: [a]). z ~ (x:xs) => Sing x -> Sing xs -> Sing z pattern SCons x xs = (:%) x xs {-# COMPLETE SNil, SCons #-} }}} But alas, GHC will not let me: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Bug.hs, interpreted ) Bug.hs:7:13: error: • Pattern synonyms can be bundled only with datatypes. • In the pattern synonym: SCons In the export: Sing(.., SCons) | 7 | module Foo (Sing(.., SCons)) where | ^^^^^^^^^^^^^^^ Failed, 0 modules loaded. }}} Can this restriction be lifted for data families? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 05:09:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 05:09:05 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances Message-ID: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code that uses a pattern synonym for a data family GADT constructor, along with a corresponding `COMPLETE` set: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data family Sing (a :: k) data instance Sing (z :: Bool) where SFalse :: Sing False STrue :: Sing True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => Sing z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: Sing (z :: Bool) -> Bool wibble STrue = True wobble :: Sing (z :: Bool) -> Bool wobble STooGoodToBeTrue = True }}} However, if you compile this, you might be surprised to find out that GHC only warns about `wibble` being non-exhaustive: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 23 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ }}} I believe the use of data families is the culprit here, since a variant of this program which doesn't use data families correctly warns for both `wibble` and `wobble`: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Foo where data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: SBool z -> Bool wibble STrue = True wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:20:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 20 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Foo.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: SFalse | 23 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 05:23:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 05:23:54 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation Message-ID: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 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: -------------------------------------+------------------------------------- I ran into this issue when attempting to fix #11785 in `TcSplice`. Here's a simple Template Haskell program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Proxy import Language.Haskell.TH newtype Foo = Foo (Proxy '[False, True, False]) $(return []) main :: IO () main = putStrLn $(reify ''Foo >>= stringE . pprint) }}} The output of this program is unfortunately noisy: {{{ $ runghc Bug.hs newtype Bug.Foo = Bug.Foo (Data.Proxy.Proxy ((':) 'GHC.Types.False ((':) 'GHC.Types.True ((':) 'GHC.Types.False ('[] :: [GHC.Types.Bool]) :: [GHC.Types.Bool]) :: [GHC.Types.Bool]) :: [GHC.Types.Bool])) }}} Somehow, we've ended up with four copies of a `[GHC.Types.Bool]` kind annotation! It definitely feels like Template Haskell could be more conservative here in choosing which types get explicit kind annotations - at the most, I'd only expect `'[]` to get one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 05:25:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 05:25:10 -0000 Subject: [GHC] #11785: Merge types and kinds in Template Haskell In-Reply-To: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> References: <047.bfff5ba2980e2ce458e592d1077c3dd1@haskell.org> Message-ID: <062.21b774c501ad00fca5018ecf88022862@haskell.org> #11785: Merge types and kinds in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3751 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I looked into completing the `TcSplice` portion of this ticket recently. While making the change was simple enough, many reified kinds became a lot noisier due to the symptoms described in #14060. It'd be nice to fix #14060 first so as not to regress the quality of reified kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 05:39:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 05:39:00 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.b1b407d28c82263e03d75042ac75fa49@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 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 RyanGlScott): [http://git.haskell.org/ghc.git/blob/7089dc2f12f9616771fc1de143e9b974157405d8:/compiler/typecheck/TcSplice.hs#l1772 Here] is why Template Haskell is choosing to attach a kind signature to every occurrence of `'[]` and `'(:)`: {{{#!hs {- Note [Kind annotations on TyConApps] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A poly-kinded tycon sometimes needs a kind annotation to be unambiguous. For example: type family F a :: k type instance F Int = (Proxy :: * -> *) type instance F Bool = (Proxy :: (* -> *) -> *) It's hard to figure out where these annotations should appear, so we do this: Suppose the tycon is applied to n arguments. We strip off the first n arguments of the tycon's kind. If there are any variables left in the result kind, we put on a kind annotation. But we must be slightly careful: it's possible that the tycon's kind will have fewer than n arguments, in the case that the concrete application instantiates a result kind variable with an arrow kind. So, if we run out of arguments, we conservatively put on a kind annotation anyway. This should be a rare case, indeed. Here is an example: data T1 :: k1 -> k2 -> * data T2 :: k1 -> k2 -> * type family G (a :: k) :: k type instance G T1 = T2 type instance F Char = (G T1 Bool :: (* -> *) -> *) -- F from above Here G's kind is (forall k. k -> k), and the desugared RHS of that last instance of F is (G (* -> (* -> *) -> *) (T1 * (* -> *)) Bool). According to the algorithm above, there are 3 arguments to G so we should peel off 3 arguments in G's kind. But G's kind has only two arguments. This is the rare special case, and we conservatively choose to put the annotation in. See #8953 and test th/T8953. -} }}} To summarize, `'[]` gets a kind annotation because its kind is `[k]`, which has a kind variable. Fair enough. But what about `'(:) 'False ('[] :: [Bool])`? The kind of `'(:)` is `forall k. k -> [k] -> [k]`. It is applied to two arguments, so we drop the first two arguments to `'(:)`'s kind, leaving us with `[k]`. That has a kind variable, so TH chooses to attach a kind signature to it. But this doesn't feel right, does it? After all, `'(:)`'s first arguments have monomorphic kinds, which makes the kind of `'(:) 'False ('[] :: [Bool])` (`[Bool]`) monomorphic as well. Therefore, I propose this additional stipulation: if the tycon is applied to any required arguments, then apply their kinds to the tycon's kind before doing further analysis. That way, in the `'(:) 'False ('[] :: [Bool])` example, we'd start with `'(:)`'s kind being `Bool -> [Bool] -> [Bool]`, drop the first two arguments and be left with `[Bool]`, which is monomorphic (and thus does not warrant a kind annotation). On the other hand, `[]`'s argument `Bool` is not required, so we end up with a kind of `[k]`, which warrants a kind annotation as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 06:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 06:32:12 -0000 Subject: [GHC] #14061: `instance Eq Dyn` Message-ID: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> #14061: `instance Eq Dyn` -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} data Dyn :: * where Dyn :: a -> Dyn }}} How to write the correct `instance Eq Dyn`, do not change `data Dyn`? {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPABLE #-} (Eq a) => GEq a a where geq = (==) instance {-# OVERLAPPING #-} GEq a b where geq _ _ = False }}} {{{#!hs instance Eq Dyn where Dyn a == Dyn b = geq a b }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Dyn.hs [1 of 1] Compiling Main ( Dyn.hs, interpreted ) Ok, modules loaded: Main. *Main> Dyn () == Dyn () False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 10:36:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 10:36:01 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.61538b1725d28e605a3d6649d296db95@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): > ..., I’m still not completely sure why this wouldn’t be a reasonable change. Try to figure out the rules: * The type family application cannot appear in a 'argument position' of a FunDep. * There might be multiple FunDeps/multi-directional. (An instance parameter might be in 'argument position' by one FunDep, but 'result position' from another.) * The variables in a type family application must be already bound by parameters appearing in 'argument position'. (Or possibly determined from those via constraints -- essentially the Liberal Coverage Conditions.) It's surely easier to have a blanket rule 'no type families'/achieve the effect with equality constraints. > The coverage condition itself is precedent for weakening of restrictions in the presence of fundeps (in that case, instance decidability), and this does not seem meaningfully different to me. Even `UndecidableInstances` doesn't allow complete chaos. If that's what you want, there's a feature request somewhere dubbed 'dysfunctional functional dependencies'. > I could be convinced by an example of the sort that SPJ alluded to, ... First consider type synonyms appearing in instance heads: {{{ {-# LANGUAGE FlexibleInstances #-} instance Multi String String where ... -- immediately expanded to instance Multi [Char] [Char] where ... -- not: instance (b0 ~ [Char]) => Multi [Char] b0 }}} OK Let's try to concoct an example per SPJ. Suppose {{{ type family Fam a where Fam a = Int instance Multi (Maybe a) (Fam a) where ... -- immediately expanded to instance Multi (Maybe a) Int where ... }}} At the use site, GHC will wait until `b` is resolved to `Int` before it will use the instance. > ... in which an instance of the form Multi X (Y a) behaves differently from (b ~ Y a) => Multi X b, but I’m not sure sure what such an example would look like or how it would differ from a user’s point of view. You mean `Y` is a type family? I'm not seeing that `instance Multi X (Y a)` would ever be a good idea: there's nothing to tell what `a` is. Even if the use site tells `Y a ~ Int`, that's no help (unless `Y` is injective -- but that's a different scenario). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 11:17:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 11:17:43 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.212ca808b5d65c1a8977e976b7fa9786@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): As per Ryan's request: https://github.com/SwiftsNamesake/Pixels -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 14:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 14:34:28 -0000 Subject: [GHC] #14053: Runtime linker failed due to a duplicate symbol definition In-Reply-To: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> References: <053.4f1087cc66f878debf7479caa1e89299@haskell.org> Message-ID: <068.ebf1559042fad5826d32d49b9a7238d9@haskell.org> #14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, Resolution: invalid | windows Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: That... is a very long list of dependencies.. The linker is correct in complaining. You're loading somehow two different versions of `process` at the same time in the same program. This would indeed lead to symbols duplication. You need to find out where in your project the dependency to `process-1.4.2.0` and `process-1.4.3.0` come from. My guess is your package configuration is messed up(check `ghc-pkg check`). Or a bug I the constraint solver for stack or cabal. But it's not a GHC bug, it's correctly rejecting loading a duplicate module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 15:28:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 15:28:06 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. Message-ID: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hi! Let's consider the following code (compiled with `-O2`, `mtl` and `criterion` needed): {{{#!hs module Main where import Prelude as import Criterion.Main import Control.Monad.State.Strict import Control.Monad.Identity repeatM :: Monad m => m a -> Int -> m () repeatM f = go where go 0 = pure () go i = f >> go (i - 1) {-# INLINE repeatM #-} incState :: MonadState Int m => m () incState = modify' (1+) ; {-# INLINE incState #-} test1, test2 :: Int -> Int test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState a >> S.get)) n ; {-# INLINE test1 #-} test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get ; {-# INLINE test2 #-} main :: IO () main = do defaultMain [ bgroup "monad transformers overhead" [ bench "test1" $ nf test1 100000000 , bench "test2" $ nf test2 100000000 ] ] }}} Functions `test1` and `test2` differ only syntactically and this difference should not affect GHC's inliner, because their implementations use fully saturated calls. The generated core for `test1` and `test2` is practically identical (there is an additional alias created for `test1`: `test1 = lvl1_rhor 'cast' ...`). The problem is that `test1` runs **3 times faster** than `test2`. As a side note - if we add more state transformers to `test1`, it optimizes them all away, while `test2` runs slower with each new transformer applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 16:17:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 16:17:05 -0000 Subject: [GHC] #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 In-Reply-To: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> References: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> Message-ID: <068.11b039fb029302c10ff7d21bd39b00f5@haskell.org> #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14041 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * related: => #14041 Comment: Is this resolved with the OpenBSD 6.1 bindist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 16:46:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 16:46:17 -0000 Subject: [GHC] #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 In-Reply-To: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> References: <053.45e29a06adb0c5bb94922ac641df7af0@haskell.org> Message-ID: <068.971ca4e482efc3232e63562f5bc17a07@haskell.org> #14044: ghc-8.2.1 installation fails on OpenBSD 6.0 -------------------------------------+------------------------------------- Reporter: romanzolotarev | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Research | needed Component: None | Version: 8.2.1 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14041 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by romanzolotarev): No. I have tried both 60 and 61 bindists. Here is the log of `ghc-8.2.1-x86_64-openbsd60-openbsd`. {{{ # mount -uo wxallowed / # PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(uname -p)/ # export PKG_PATH # ftp https://downloads.haskell.org/~ghc/8.2.1/ghc-8.2.1-x86_64-openbsd60-openbsd.tar.xz # pkg_add xz gtar gmake gmp # unxz ghc-8.2.1-x86_64-openbsd60-openbsd.tar.xz # tar xvf ghc-8.2.1-x86_64-openbsd60-openbsd.tar # cd ghc-8.2.1 # ./configure # alias make=gmake # make install ... ghc-cabal: can't load library 'libc.so.89.3' gmake[1]: *** [ghc.mk:991: install_packages] Error 4 gmake: *** [Makefile:51: install] Error 2 # find / -name libc.so* /usr/lib/libc.so.88.0 /usr/lib/libc.so.88.0.a # uname -a OpenBSD jupiter.romanzolotarev.com 6.0 GENERIC#2148 amd64 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 16:54:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 16:54:08 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.f5e10aebf8d296e9014bc9345ecc27d4@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed you were right, nh2; the current state of affairs looks quite bad. Thanks for looking at this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 18:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 18:34:47 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.6008e21c73e7b6e6edcf2dd8f2502bf8@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! Let's consider the following code (compiled with `-O2`, `mtl` and > `criterion` needed): > > {{{#!hs > module Main where > > import Prelude as > import Criterion.Main > import Control.Monad.State.Strict > import Control.Monad.Identity > > repeatM :: Monad m => m a -> Int -> m () > repeatM f = go where > go 0 = pure () > go i = f >> go (i - 1) > {-# INLINE repeatM #-} > > incState :: MonadState Int m => m () > incState = modify' (1+) ; {-# INLINE incState #-} > > test1, test2 :: Int -> Int > test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState > a >> S.get)) n ; {-# INLINE test1 #-} > test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get > ; {-# INLINE test2 #-} > > main :: IO () > main = do > defaultMain > [ bgroup "monad transformers overhead" > [ bench "test1" $ nf test1 100000000 > , bench "test2" $ nf test2 100000000 > ] > ] > }}} > > Functions `test1` and `test2` differ only syntactically and this > difference should not affect GHC's inliner, because their implementations > use fully saturated calls. The generated core for `test1` and `test2` is > practically identical (there is an additional alias created for `test1`: > `test1 = lvl1_rhor 'cast' ...`). > > The problem is that `test1` runs **3 times faster** than `test2`. > > As a side note - if we add more state transformers to `test1`, it > optimizes them all away, while `test2` runs slower with each new > transformer applied. New description: Hi! Let's consider the following code (compiled with `-O2`, `mtl` and `criterion` needed): {{{#!hs module Main where import Prelude as import Criterion.Main import Control.Monad.State.Strict import Control.Monad.Identity repeatM :: Monad m => m a -> Int -> m () repeatM f = go where go 0 = pure () go i = f >> go (i - 1) {-# INLINE repeatM #-} incState :: MonadState Int m => m () incState = modify' (1+) ; {-# INLINE incState #-} test1, test2 :: Int -> Int test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState a >> get)) n ; {-# INLINE test1 #-} test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get ; {-# INLINE test2 #-} main :: IO () main = do defaultMain [ bgroup "monad transformers overhead" [ bench "test1" $ nf test1 100000000 , bench "test2" $ nf test2 100000000 ] ] }}} Functions `test1` and `test2` differ only syntactically and this difference should not affect GHC's inliner, because their implementations use fully saturated calls. The generated core for `test1` and `test2` is practically identical (there is an additional alias created for `test1`: `test1 = lvl1_rhor 'cast' ...`). The problem is that `test1` runs **3 times faster** than `test2`. As a side note - if we add more state transformers to `test1`, it optimizes them all away, while `test2` runs slower with each new transformer applied. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:31:10 -0000 Subject: [GHC] #14042: Misleading error message when type family is used in datatype's return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.a95cab4e2f00e922c8ca43c94cab8def@haskell.org> #14042: Misleading error message when type family is used in datatype's return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Well, the problem is that the result is not `*`. It's Something Else. It doesn't really have to do with type families, just the rigidity around `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:33:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:33:54 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.dd97124807faa1b98e614b3dd0c7e8fc@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 goldfire): I guess I'm saying that `newName "foo"` and `newName "foo"` do ''not'' create duplicate names with different uniques... they just create different names that get rendered similarly when pretty-printing. Any implementation that does so is fine by me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:38:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:38:54 -0000 Subject: [GHC] #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" Message-ID: <044.3cef4744462e3ff17df5a112d19c05bf@haskell.org> #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: rcook | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Backpack | 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: -------------------------------------+------------------------------------- Using GHC 8.2.1: {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 }}} And compiling with `--backpack` as follows: {{{ > ghc --backpack foo.bkp [1 of 4] Processing foo-indef [1 of 2] Compiling Str[sig] ( foo-indef\Str.hsig, nothing ) [2 of 2] Compiling Foo ( foo-indef\Foo.hs, nothing ) [2 of 4] Processing foo-string Instantiating foo-string [1 of 1] Compiling Str ( foo-string\Str.hs, foo- string\Str.o ) [3 of 4] Processing foo-int Instantiating foo-int [1 of 1] Compiling Str ( foo-int\Str.hs, foo-int\Str.o ) [4 of 4] Processing main ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): no package name CallStack (from HasCallStack): error, called at compiler\backpack\DriverBkp.hs:573:32 in ghc:DriverBkp Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [foo-indef/Foo.hi] Error 1 }}} See attached `foo.bkp` file. While the Backpack file ''is'' invalid, in that the `main` unit mentions the `foo` dependency, which does not exist, this shouldn't lead to a GHC panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:39:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:39:17 -0000 Subject: [GHC] #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" In-Reply-To: <044.3cef4744462e3ff17df5a112d19c05bf@haskell.org> References: <044.3cef4744462e3ff17df5a112d19c05bf@haskell.org> Message-ID: <059.ce192cebe017829f02eb0240a1b44fb7@haskell.org> #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: rcook | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Backpack 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: | -------------------------------------+------------------------------------- Changes (by rcook): * Attachment "foo.bkp" added. Example Backpack file that demonstrates bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:49:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:49:02 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.0d9e2de3ad821df51135ebd4f23d8915@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm a little uncomfortable that this requires two declarations of the name: the `data family Sing :: ...` and the `class Sing ...`. More broadly, I think the code might be easier to read using two different names, frankly. But maybe others disagree. I don't see any major problems with adding it -- it's just a question of programmability (and maintenance burden). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:49:28 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.089c25ed7a7c34214fbe56b5b987fd47@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 21:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 21:55:17 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.38a4b71e6bf681f4da0ada6ebfb8c860@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * cc: danilo2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 22:27:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 22:27:34 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.c6ac80a1527d16864f549003c1025ea7@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): When testing my change on Windows, I found that the `if (isSock){ select(...) }` part seems completely broken on Windows. That is because on Windows `FD_SETSIZE` defaults to 64, but pretty much all GHC programs seem to have > 64 FDs open, so you can't actually create a socket on which you can `select()`. It errors with `fdReady: fd is too big` even with an example as simple as [https://github.com/nh2/ghc-socket- test/blob/af74bb348e88f3f7ca717c70540936fea1293257/ghc-socket-test.hs this] (in this case, on my machine the `fd` is `284`): {{{ {-# LANGUAGE OverloadedStrings #-} import Control.Monad (forever) import Network.Socket import System.IO -- Simple echo server: Reads up to 10 chars from network, echoes them back. -- Uses the Handle API so that `hWaitForInput` can be used. main :: IO () main = do sock <- socket AF_INET Stream 0 setSocketOption sock ReuseAddr 1 bind sock (SockAddrInet 1234 0x0100007f) -- 0x0100007f == 127.0.0.1 localhost listen sock 2 forever $ do (connSock, _connAddr) <- accept sock putStrLn "Got connection" h <- socketToHandle connSock ReadWriteMode hSetBuffering h NoBuffering ready <- hWaitForInput h (5 * 1000) -- 5 seconds putStrLn $ "Ready: " ++ show ready line <- hGetLine h putStrLn "Got line" hPutStrLn h ("Got: " ++ line) hClose h }}} I'm not sure how this was not discovered earlier; for #13525 (where `fdReady()` breaking completely was also discovered late) at least it failed only when the timeout was non-zero, which is not used in ghc beyond in `hWaitForInput`, but in this Windows socket case it breaks even on the 0-timeout. Maybe there is not actually anybody who uses sockets as handles on Windows? It seems an approriate workaround for now is to increase `FD_SETSIZE` (which is possible on Windows and BSD, see [https://stackoverflow.com/questions/7976388/increasing-limit-of-fd- setsize-and-select here]) on Windows. A real fix would be to move to IO Completion Ports, and thus get rid of the last use of `select()` (the other platforms already use `poll()` but Windows doesn't have that). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 22:27:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 22:27:58 -0000 Subject: [GHC] #14042: Misleading error message when type family is used in datatype's return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.6ebbcb93d65c9ce57596e16b682535e6@haskell.org> #14042: Misleading error message when type family is used in datatype's return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, newcomer 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): All I'll say is that I think it'd be worth singling out type families as a special case for error messages. FWIW, the example I actually tried (but boiled down to just `Id Type` for demonstration purposes) was something like this: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import Data.Kind type family MkFun (args :: [Type]) (ret :: Type) :: Type where MkFun '[] ret = ret MkFun (arg:args) ret = arg -> MkFun args ret data Foo (args :: [Type]) :: MkFun args Type }}} This is a perfectly natural thing to do in a dependently typed language like Idris: {{{#!idris MkFun : (args : List Type) -> Type -> Type MkFun [] ret = ret MkFun (arg::args) ret = arg -> MkFun args ret data Foo : (args : List Type) -> MkFun args Type }}} So I was quite surprised to find out that GHC can't do the same thing, even with `TypeInType`. It would be nice to mention in the error message that type families are the culprit in that particular scenario, since one would intuitively expect the language to recognize the fact that `MkFun args Type` does in fact expand to something which ends in `Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 22:40:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 22:40:53 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.dde71e968ac75acf9922830ccaac55df@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Addition to above comment: Probably the only time that worked was before commit [https://github.com/ghc/ghc/commit/b0316cdb10fbd9eaca7ede28c7bb3eb19f7766bf b0316cdb] (#9169) that added the `FD_SETSIZE` check -- in which case it probably only worked due to writing to (and likely corrupting) out-of- bounds memory beyond the size of the `fd_set`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 23:00:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 23:00:33 -0000 Subject: [GHC] #14061: `instance Eq Dyn` In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.5eb86c1289301e27a025344dc723bd75@haskell.org> #14061: `instance Eq Dyn` -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 AntC): Repeat of ticket #14004. The answer is already posted there. You can't make `instance Eq Dyn` with that definition for `Dyn`. But there are two suggestions for different approaches. This is not a bug; not a feature request. @zaoqi please do not use Trac as a help forum: use StackOverflow or reddit or haskell cafe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 23:14:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 23:14:58 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.ee14dd93978e2a4c44df37b448bba18e@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I have pushed a workaround to my branch ​[https://github.com/ghc/ghc/compare/ghc-8.2.1-release...nh2:ghc-8.2.1 -improve-fdRready-precision ghc-8.2.1-improve-fdRready-precision], namely commit [https://github.com/nh2/ghc/commit/1d037a16251751e98d4302f4be1e5659c3240958 1d037a16]. This completes my testing of my branch on Windows. I have tested the 4 of the 5 possible branches that `fdReady()` can take on Windows: 1. Testing the `FILE_TYPE_PIPE` case suceeded with `ghc-bug-13497 -accuracy-test.hs` (from [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:18 comment 18]), by running it from the MSYS2 Mingw-w64 console (NOT `cmd.exe`!) 2. Testing the `FILE_TYPE_DISK` case succeeded with the following file `ghc-bug-13497-windows-file-test.hs`: {{{ import System.IO main = do writeFile "testfile" "hello" handle <- openFile "testfile" ReadMode hWaitForInput handle (5 * 1000) }}} 3. Testing the `FILE_TYPE_CHAR` case suceeded by running `ghc-bug-13497 -accuracy-test.hs` (see above) , but this time from `cmd.exe`. Here, focusing and unfocusing the Window triggers `EventType == FOCUS_EVENT` so that our loop is executed (I confirmed this with a print in the loop). 4. Testing the `if (isSock)` case succeded with the echo server example given in the previous comment. 5. I did not test the `default:` case ([https://github.com/nh2/ghc/blob/1d037a16251751e98d4302f4be1e5659c3240958/libraries/base/cbits/inputReady.c#L231 this one]), because I don't know how to trigger it. There are 3 cases in which this branch could be taken according to the `GetFileType()` [https://msdn.microsoft.com/en- us/library/windows/desktop/aa364960(v=vs.85).aspx documentation]: A. `FILE_TYPE_REMOTE`, which seems impossible to create on modern Windows B. `FILE_TYPE_UNKNOWN`, for which it is literally unknown on how it can be created C. The very bottom of the `FILE_TYPE_PIPE` case, when `/* PeekNamedPipe didn't work - fall through to the general case */` happens. I don't know how to trigger this. Simon Marlow introduced this logic 9 years ago in commit [https://github.com/nh2/ghc/commit/1b0906e072344376ec7cb95afe314f2157b62b20 1b0906e0], so maybe he knows. In any case, with this testing done I'm reasonably confident that my branch doesn't regress Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 30 23:23:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Jul 2017 23:23:44 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.e8fe69b4f28b59555f5ba735f1fd7893@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Another thing I found: The comment on top of `fdReady()` says: {{{ "Input is available" is defined as 'can I safely read at least a *character* from this file object without blocking?' }}} But this seems to be not true in the general case: If the FD is for a socket, then it is only true when that socket is non- blocking. `man 2 poll` (see [https://linux.die.net/man/2/poll here]) describes this: > Bugs > > See the discussion of spurious readiness notifications under the BUGS section of select(2). `man 2 select` (see [https://linux.die.net/man/2/poll here]) says: > Under Linux, `select()` may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use `O_NONBLOCK` on sockets that should not block. I have not investigated whether anywhere in GHC `fdReady()` is potentially called with a not-nonblocking socket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 01:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 01:19:31 -0000 Subject: [GHC] #14006: Heap profiling ghc gives hp2ps error In-Reply-To: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> References: <045.33d3453df6819e51591e1886ab5b1893@haskell.org> Message-ID: <060.eb8981e5f6b72913eaa6864e7eebf10a@haskell.org> #14006: Heap profiling ghc gives hp2ps error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 bgamari]: > Strangely I've been unable to reproduce this. Did you use a perf build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 01:39:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 01:39:44 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.9c8370c365448b62ed9fbe19b2074c39@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * milestone: => 8.4.1 Comment: By 8.4.1, as Simon says in comment 12: it would be good if [at least] the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 01:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 01:59:49 -0000 Subject: [GHC] #14061: `instance Eq Dyn` In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.965981459bad04d1534d8f5e56aad145@haskell.org> #14061: `instance Eq Dyn` -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 02:00:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 02:00:08 -0000 Subject: [GHC] #14004: G In-Reply-To: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> References: <044.31c32448ea5ec18eeb8f99bd2b4af965@haskell.org> Message-ID: <059.b11a1bae93c4b1da5486f8be3ab12d21@haskell.org> #14004: G -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 02:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 02:26:12 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.77b2510b9d7352f3488e42cf5eba237f@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 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 goldfire): I'm not sure what "if the tycon is applied to any required arguments, then apply their kinds to the tycon's kind before doing further analysis" means. I suppose it could mean that you try to solve for the kind variables by doing unification and seeing if unification fixes the kind variables. Then apply the unifying substitution to the remainder of the kind. But that's quite a bit of work! Define "remainder of the tycon's kind" to mean the portion of the kind left over after all components of the kind corresponding to provided type arguments are removed. Do no instantiation of kind variables here. The current rule is: A. Include a kind annotation when the remainder of the tycon's kind mentions a kind variable. What if we change it to: B. Include a kind annotation when the remainder of the tycon's kind mentions a kind variable ''and'' that kind variable is not mentioned in any arguments that have been dropped (when finding the remainder). (But don't count occurrences in the arguments to non-injective type families.) Why is this new rule good? Because we're assuming that any reified type will have a fixed, known kind. When reifying a type application, we reify all its type arguments as well. Thus, all the type arguments will have a fixed, known kind. And thus any kind variables in the tycon's kind mentioned in that argument's expected kind will also be fixed. The exception here is for type families, which aren't injective. Happily, this keeps the annotation on `'[]` but drops it on `'(:)`. I will restate (B) to be a bit more implementable: * We have a tyconapp `T ty1 ... tyn`. The tycon `T` has kind `ki0`. * If `T` is oversaturated, no annotation is necessary. Otherwise, we can assume `ki0` has the form `forall k1 ... km. s1 -> ... -> sn -> p`. * Let `K` be the set of kind variables (that is, a subset of `{k1, ..., km}`) that occur in "injective positions" in `s1 ... sn`. An injective position in a type `ty` is either `ty` itself, an injective position within an injective argument to a tycon, an injective position in a function, or an injective position in the argument to a type variable. * Include an annotation only when `p` (the remainder of the tycon's kind) contains a kind variable ''not'' in the set `K`. What do we think? Might this work? I do think this is considerably easier than invoking unification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 02:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 02:49:46 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.274a5435a8cc91c7d7d208fcd74ba089@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 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 RyanGlScott): After re-reading, I'm not sure myself what "if the tycon is applied to any required arguments, then apply their kinds to the tycon's kind before doing further analysis" means. But you've laid out a much better plan of attach than I ever could. Thanks! > If `T` is oversaturated, no annotation is necessary. Otherwise, we can assume `ki0` has the form `forall k1 ... km. s1 -> ... -> sn -> p`. What happens if we have a dependent quantifier like `forall km -> s1 -> ... -> sn -> p`? Would `km` be included in `K`? My hunch is "yes". > An injective position in a type `ty` is either `ty` itself, an injective position within an injective argument to a tycon, an injective position in a function, or an injective position in the argument to a type variable. The "`ty` itself" bit confuses me. Did you mean "a `ty` itself is in an injective position if `ty` is a tyvar"? I'm guessing you didn't intend for it to be interpreted as "a `ty` itself is always in an injective position", since that would mean that all the variables in `InjTyFam a ... z` would count, where `InjTyFam` is an injective type family. > I do think this is considerably easier than invoking unification. Certainly. But I know close to nothing about how GHC's unifier works, so this is a pretty low bar for me personally :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 03:06:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 03:06:01 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind (was: Misleading error message when type family is used in datatype's return kind) In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.8239ac447afb210aa43db14343a08a84@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType, TypeFamilies, newcomer => TypeInType, TypeFamilies Old description: > This typechecks: > > {{{#!hs > {-# LANGUAGE TypeInType #-} > > import Data.Kind > > type Id (a :: Type) = a > > data Foo :: Id Type > }}} > > But changing the type synonym to a type family causes it to fail: > > {{{#!hs > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeInType #-} > > import Data.Kind > > type family Id (a :: Type) :: Type where > Id a = a > > data Foo :: Id Type > }}} > {{{ > $ ghci Foo.hs > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Main ( Foo.hs, interpreted ) > > Foo.hs:9:1: error: > • Kind signature on data type declaration has non-* return kind > Id * > • In the data declaration for ‘Foo’ > | > 9 | data Foo :: Id Type > | ^^^^^^^^ > }}} > > That error message is wrong, since `Id * = *`. New description: This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. And, besides, the definition should be accepted. EDIT: This was originally about the error message. But comment:9 changes the goal of the bug to fix the behavior. -- Comment: Ah! So I hadn't been aware of a use-case of this non-feature other than to annoy the type checker. I think, then, that this could be called a proper bug, not just a bad error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 03:14:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 03:14:57 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") Message-ID: <043.996442976c5d50d07afa88e2354bce42@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The scenario showed as below: {{{ # This is a FreeBSD Jail for testing $ freebsd-version 11.1-RELEASE $ pkg info # (related packages only) binutils-2.28,1 GNU binary tools gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_2 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libiconv-1.14_10 Character set conversion library libunistring-0.9.7 Unicode string library mpc-1.0.3 Library of complex numbers with arbitrarily high precision mpfr-3.1.5_1 Library for multiple-precision floating- point computations perl5-5.24.1_1 Practical Extraction and Report Language $ ls -l /usr/local/lib/lib{iconv,charset,gmp}.* -rw-r--r-- 1 root wheel 6864 Jul 13 09:10 /usr/local/lib/libcharset.a lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so -> libcharset.so.1.0.0 lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so.1 -> libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 10733 Jul 13 09:10 /usr/local/lib/libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 1252196 Jul 13 09:23 /usr/local/lib/libgmp.a lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so -> libgmp.so.10.3.2 lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so.10 -> libgmp.so.10.3.2 -rwxr-xr-x 1 root wheel 531728 Jul 13 09:23 /usr/local/lib/libgmp.so.10.3.2 -rw-r--r-- 1 root wheel 1110392 Jul 13 09:10 /usr/local/lib/libiconv.a lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so -> libiconv.so.2.5.1 lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1 -rw-r--r-- 1 root wheel 1076449 Jul 13 09:10 /usr/local/lib/libiconv.so.2.5.1 # installed using # env CC=/usr/local/bin/gcc5 LDFLAGS='-Wl,-rpath=/usr/local/lib/gcc5' ./configure --prefix=/home/ghc $ /home/ghc/bin/ghc --numeric-version 8.2.1 $ cat /home/ghc/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "/usr/local/bin/gcc5"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","/usr/local/bin/gcc5"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/local/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ /home/ghc/bin/ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> (!!6) $ scanl (*) 1 [1..] 720 $ cat Main.hs module Main (main) where main :: IO () main = putStrLn "hello world" $ /home/ghc/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... In file included from /home/ghc/lib/ghc-8.2.1/include/rts/Threads.h:19:0: error: 0, from /home/ghc/lib/ghc-8.2.1/include/Rts.h:173, from /tmp/ghc28144_0/ghc_4.c:1: /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:266:9: error: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ | 266 | typedef __vm_ooffset_t vm_ooffset_t; | ^ /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:268:9: error: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ | 268 | typedef __vm_pindex_t vm_pindex_t; | ^ `gcc5' failed in phase `C Compiler'. (Exit code: 1) }}} On my FreeBSD 10.3 box: {{{ $ freebsd-version 10.3-STABLE $ pkg info binutils-2.28,1 GNU binary tools gcc-5.4.0_2 Meta-port for the default version of the GNU Compiler Collection gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_3 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libffi-3.2.1 Foreign Function Interface libiconv-1.14_10 Character set conversion library perl5-5.24.1_1 Practical Extraction and Report Language $ cat ./ghc-8.2.1-bin/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "NO"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ ./ghc-8.2.1-bin/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main hello, world! }}} I also noticed that using FreeBSD's strip (from elftoolchain), the {{{ Installing library in /home/ghc/lib/ghc-8.2.1/ghc-prim-0.5.1.0 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /integer-gmp dist-install "strip" '' '/home/ghc' '/home/ghc/lib/ghc-8.2.1' '/home/ghc/share/doc/ghc- 8.2.1/html/libraries' 'v p dyn' }}} phase will be a bit longer than GNU's strip. (Tested by put my $LOCALBASE/bin ahead in $PATH). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 03:27:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 03:27:43 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.5ef330db96bcefaf7d78c57f749edc5f@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 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 goldfire): Yes, a dependent quantifier would be in `K`. Yes about your initial understanding about "`ty` itself": I was saying that the tyvar `a` is in an injective position within the type `a`. Actually, GHC's pure unifier is easy enough to invoke, but I think that route is likely to be harder to reason about than my algorithm above. Yes, it's a bit long to state, but I think just a few lines of Haskell code will implement it nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 04:36:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 04:36:28 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.401a92d50cb239ec89121bb688f14ee1@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I believe this is actually a [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221111|FreeBSD issue]]. Can you confirm that the fix proposed on that ticket resolves the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 04:51:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 04:51:13 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.03b0226c48fea9e0d4f014d0e5be4ace@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12494.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"49e334c8ea98cd5ecc81cfe10827538182815723/ghc" 49e334c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49e334c8ea98cd5ecc81cfe10827538182815723" Allow Windows to set blank environment variables Test Plan: ./validate on harbormaster Reviewers: austin, hvr, bgamari, erikd, Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #12494 Differential Revision: https://phabricator.haskell.org/D3726 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 04:53:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 04:53:46 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.e2801d741e4a10212e879e9476e070dc@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/T12494.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 05:32:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 05:32:34 -0000 Subject: [GHC] #14060: TH-reified types can suffer from kind signature oversaturation In-Reply-To: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> References: <050.23e4205a9ebcfe16bb36b3d03dc6cd54@haskell.org> Message-ID: <065.bbe7d45da8fb92a01da532a92f210861@haskell.org> #14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3807 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 05:52:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 05:52:05 -0000 Subject: [GHC] #14061: reflection (was: `instance Eq Dyn`) In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.a23f2413b492fbf8ecbef7ba6198574d@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by zaoqi): * component: Compiler => Runtime System Old description: > {{{#!hs > {-# LANGUAGE KindSignatures, GADTs #-} > data Dyn :: * where > Dyn :: a -> Dyn > }}} > How to write the correct `instance Eq Dyn`, do not change `data Dyn`? > > {{{#!hs > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} > > class GEq a b where > geq :: a -> b -> Bool > > instance {-# OVERLAPPABLE #-} (Eq a) => GEq a a where > geq = (==) > > instance {-# OVERLAPPING #-} GEq a b where > geq _ _ = False > }}} > {{{#!hs > instance Eq Dyn where > Dyn a == Dyn b = geq a b > }}} > > {{{ > GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help > Prelude> :load Dyn.hs > [1 of 1] Compiling Main ( Dyn.hs, interpreted ) > Ok, modules loaded: Main. > *Main> Dyn () == Dyn () > False > }}} New description: {{{#!hs {-# LANGUAGE KindSignatures, GADTs #-} data Dyn :: * where Dyn :: a -> Dyn }}} How to write the correct `instance Eq Dyn`, do not change `data Dyn`? {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class GEq a b where geq :: a -> b -> Bool instance {-# OVERLAPPABLE #-} (Eq a) => GEq a a where geq = (==) instance {-# OVERLAPPING #-} GEq a b where geq _ _ = False }}} {{{#!hs instance Eq Dyn where Dyn a == Dyn b = geq a b }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Dyn.hs [1 of 1] Compiling Main ( Dyn.hs, interpreted ) Ok, modules loaded: Main. *Main> Dyn () == Dyn () False }}} If Haskell supports reflections like Java, -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 05:52:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 05:52:35 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.7f7a474780f7d272ec47df33c09f9cd4@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by zaoqi): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 06:28:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 06:28:17 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.993db221e3c56ae9d493f357fd945bdd@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): Replying to [comment:1 bgamari]: > I believe this is actually a [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221111|FreeBSD issue]]. Can you confirm that the fix proposed on that ticket resolves the issue? Yes, it was due to the package was built unpatched.\\ I reinstalled gcc5 from the ports collection, it did solve the problem. However, the [https://www.reddit.com/r/haskell/comments/6oz5q3/announce_ghc_821_available/dkoy3m3/ ld.gold error] I posted on reddit remained the same. Check this out: {{{ $ /home/ghc/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... /usr/local/bin/ld.gold: error: cannot find -liconv /usr/local/bin/ld.gold: error: cannot find -lcharset /usr/local/bin/ld.gold: error: cannot find -lgmp /home/ghc/lib/ghc-8.2.1/base-4.10.0.0/libHSbase-4.10.0.0.a(PrelIOUtils.o):function localeEncoding: error: undefined reference to 'locale_charset' /home/ghc/lib/ghc-8.2.1/base-4.10.0.0/libHSbase-4.10.0.0.a(iconv.o):function hs_iconv_open: error: undefined reference to 'libiconv_open' /home/ghc/lib/ghc-8.2.1/base-4.10.0.0/libHSbase-4.10.0.0.a(iconv.o):function hs_iconv: error: undefined reference to 'libiconv' /home/ghc/lib/ghc-8.2.1/base-4.10.0.0/libHSbase-4.10.0.0.a(iconv.o):function hs_iconv_close: error: undefined reference to 'libiconv_close' collect2: error: ld returned 1 exit status `gcc5' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 06:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 06:44:08 -0000 Subject: [GHC] #14065: Type inference Message-ID: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> #14065: Type inference -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import Control.Exception data Nat = Z | S Nat deriving (Eq, Ord) instance Enum Nat where succ = S pred (S x) = x pred _ = throw Underflow toEnum 0 = Z toEnum x | x < 0 = throw Underflow | otherwise = S . toEnum $ pred x fromEnum Z = 0 fromEnum (S x) = succ $ fromEnum x enumFrom x = x : enumFrom (S x) instance Num Nat where Z + x = x (S x) + y = S $ x + y Z * _ = Z (S x) * y = y + (x * y) abs = id signum Z = Z signum _ = S Z fromInteger 0 = Z fromInteger x | x < 0 = throw Underflow | otherwise = S . fromInteger $ pred x x - Z = x (S x) - (S y) = x - y _ - _ = throw Underflow negate Z = Z negate _ = throw Underflow instance Real Nat where toRational = toRational . toInteger instance Integral Nat where quot x y = fromInteger $ quot (toInteger x) (toInteger y) rem x y = fromInteger $ rem (toInteger x) (toInteger y) div x y = fromInteger $ div (toInteger x) (toInteger y) mod x y = fromInteger $ mod (toInteger x) (toInteger y) quotRem x y = let (x, y) = quotRem (toInteger x) (toInteger y) in (fromInteger x, fromInteger y) divMod x y = let (x, y) = divMod (toInteger x) (toInteger y) in (fromInteger x, fromInteger y) toInteger Z = 0 toInteger (S x) = succ $ toInteger x data Vec :: Nat -> * -> * where Nil :: Vec Z a Cons :: a -> Vec x a -> Vec (S x) a data ReadableVec :: * -> * where ReadableVec :: Vec x a -> ReadableVec a instance Read a => Read (ReadableVec a) where readsPrec x s = map (\(xs, r) -> (l2rv xs, r)) (readsPrec x s) where l2rv [] = ReadableVec Nil l2rv (x : xs) = case l2rv xs of ReadableVec rs -> ReadableVec (Cons x rs) instance Show a => Show (Vec x a) where showsPrec p xs = showsPrec p (ReadableVec xs) instance Show a => Show (ReadableVec a) where showsPrec p xs = showsPrec p (rv2l xs) where rv2l :: ReadableVec x -> [x] rv2l (ReadableVec Nil) = [] rv2l (ReadableVec (Cons x xs)) = x : rv2l (ReadableVec xs) }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Vec.hs [1 of 1] Compiling Main ( Vec.hs, interpreted ) Ok, modules loaded: Main. }}} {{{#!hs --Copyright (C) 2017 Zaoqi --This program is free software: you can redistribute it and/or modify --it under the terms of the GNU Affero General Public License as published --by the Free Software Foundation, either version 3 of the License, or --(at your option) any later version. --This program is distributed in the hope that it will be useful, --but WITHOUT ANY WARRANTY; without even the implied warranty of --MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the --GNU Affero General Public License for more details. --You should have received a copy of the GNU Affero General Public License --along with this program. If not, see . {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import Control.Exception data Nat = Z | S Nat deriving (Eq, Ord) instance Enum Nat where succ = S pred (S x) = x pred _ = throw Underflow toEnum 0 = Z toEnum x | x < 0 = throw Underflow | otherwise = S . toEnum $ pred x fromEnum Z = 0 fromEnum (S x) = succ $ fromEnum x enumFrom x = x : enumFrom (S x) instance Num Nat where Z + x = x (S x) + y = S $ x + y Z * _ = Z (S x) * y = y + (x * y) abs = id signum Z = Z signum _ = S Z fromInteger 0 = Z fromInteger x | x < 0 = throw Underflow | otherwise = S . fromInteger $ pred x x - Z = x (S x) - (S y) = x - y _ - _ = throw Underflow negate Z = Z negate _ = throw Underflow instance Real Nat where toRational = toRational . toInteger instance Integral Nat where quot x y = fromInteger $ quot (toInteger x) (toInteger y) rem x y = fromInteger $ rem (toInteger x) (toInteger y) div x y = fromInteger $ div (toInteger x) (toInteger y) mod x y = fromInteger $ mod (toInteger x) (toInteger y) quotRem x y = let (x, y) = quotRem (toInteger x) (toInteger y) in (fromInteger x, fromInteger y) divMod x y = let (x, y) = divMod (toInteger x) (toInteger y) in (fromInteger x, fromInteger y) toInteger Z = 0 toInteger (S x) = succ $ toInteger x data Vec :: Nat -> * -> * where Nil :: Vec Z a Cons :: a -> Vec x a -> Vec (S x) a data ReadableVec :: * -> * where ReadableVec :: Vec x a -> ReadableVec a instance Read a => Read (ReadableVec a) where readsPrec x s = map (\(xs, r) -> (l2rv xs, r)) (readsPrec x s) where l2rv [] = ReadableVec Nil l2rv (x : xs) = case l2rv xs of ReadableVec rs -> ReadableVec (Cons x rs) instance Show a => Show (Vec x a) where showsPrec p xs = showsPrec p (ReadableVec xs) instance Show a => Show (ReadableVec a) where showsPrec p xs = showsPrec p (rv2l xs) where --rv2l :: ReadableVec x -> [x] rv2l (ReadableVec Nil) = [] rv2l (ReadableVec (Cons x xs)) = x : rv2l (ReadableVec xs) }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Vec.hs [1 of 1] Compiling Main ( Vec.hs, interpreted ) Vec.hs:79:22: error: • Could not deduce (Show a0) arising from a use of ‘showsPrec’ from the context: Show a bound by the instance declaration at Vec.hs:78:10-39 The type variable ‘a0’ is ambiguous These potential instances exist: instance Show ArithException -- Defined in ‘GHC.Exception’ instance Show ErrorCall -- Defined in ‘GHC.Exception’ instance Show SomeException -- Defined in ‘GHC.Exception’ ...plus 27 others ...plus 12 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: showsPrec p (rv2l xs) In an equation for ‘showsPrec’: showsPrec p xs = showsPrec p (rv2l xs) where rv2l (ReadableVec Nil) = [] rv2l (ReadableVec (Cons x xs)) = x : rv2l (ReadableVec xs) In the instance declaration for ‘Show (ReadableVec a)’ Vec.hs:82:34: error: • Couldn't match expected type ‘t’ with actual type ‘[t0]’ ‘t’ is untouchable inside the constraints: x ~ 'Z bound by a pattern with constructor: Nil :: forall a. Vec 'Z a, in an equation for ‘rv2l’ at Vec.hs:82:27-29 ‘t’ is a rigid type variable bound by the inferred type of rv2l :: ReadableVec t1 -> t at Vec.hs:82:9 Possible fix: add a type signature for ‘rv2l’ • In the expression: [] In an equation for ‘rv2l’: rv2l (ReadableVec Nil) = [] In an equation for ‘showsPrec’: showsPrec p xs = showsPrec p (rv2l xs) where rv2l (ReadableVec Nil) = [] rv2l (ReadableVec (Cons x xs)) = x : rv2l (ReadableVec xs) • Relevant bindings include rv2l :: ReadableVec t1 -> t (bound at Vec.hs:82:9) Vec.hs:83:46: error: • Couldn't match type ‘t’ with ‘[t1]’ ‘t’ is untouchable inside the constraints: x ~ 'S x1 bound by a pattern with constructor: Cons :: forall a (x :: Nat). a -> Vec x a -> Vec ('S x) a, in an equation for ‘rv2l’ at Vec.hs:83:28-36 ‘t’ is a rigid type variable bound by the inferred type of rv2l :: ReadableVec t1 -> t at Vec.hs:82:9 Possible fix: add a type signature for ‘rv2l’ Expected type: ReadableVec t1 -> [t1] Actual type: ReadableVec t1 -> t • In the second argument of ‘(:)’, namely ‘rv2l (ReadableVec xs)’ In the expression: x : rv2l (ReadableVec xs) In an equation for ‘rv2l’: rv2l (ReadableVec (Cons x xs)) = x : rv2l (ReadableVec xs) • Relevant bindings include xs :: Vec x1 t1 (bound at Vec.hs:83:35) x :: t1 (bound at Vec.hs:83:33) rv2l :: ReadableVec t1 -> t (bound at Vec.hs:82:9) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 07:31:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 07:31:04 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.b1ab618fe4ae0145378f624890d3168a@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): There must be a quadratic algorithm in here! Might someone dig a big deeper? Probably profiling would nail it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 07:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 07:46:52 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.3b7de0a1333b33d6e77bb15aaed6bfc0@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohho): I have tried various link options in `settings` file. It seemed that, set an empty "C compiler link flags", i.e., remove "` -fuse-ld=gold`", it fell back to the plain-old `/usr/local/bin/ld`, then the whole thing worked without any problem. I don't know which side to blame, GHC or GCC? P./S. I ktrace'd both settings to make sure: {{{ # -fuse-ld=gold 52022 ghc CALL read(0x10,0x80d50d010,0x2000) 52022 ghc GIO fd 16 read 880 bytes "collect2 version 5.4.0 /usr/local/bin/ld.gold -plugin /usr/local/libexec/gcc5/gcc/x86_64 -portbld-freebsd11.1/5.4.0/liblto_plugin.so -plugin- opt=/usr/local/libexec/gcc5/gcc/x86_64-portbld\ -freebsd11.1/5.4.0/lto-wrapper -plugin- opt=-fresolution=/tmp//cc5NWh3O.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-thro\ ugh=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass- through=-lgcc_s --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/\ local/lib/gcc5/gcc/x86_64-portbld-freebsd11.1/5.4.0/crtbegin.o -L/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.1/5.4.0 -L/usr/local/lib/gcc5/gcc/x86_64-portbld-\ freebsd11.1/5.4.0/../../.. --version -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc5/gcc/x86_64-portbld-f\ reebsd11.1/5.4.0/crtend.o /usr/lib/crtn.o ... 52022 ghc RET fstat 0 52022 ghc CALL ftruncate(0xc,0) 52022 ghc RET ftruncate 0 52022 ghc CALL ioctl(0xc,TIOCGETA,0x7fffffffa860) 52022 ghc RET ioctl -1 errno 25 Inappropriate ioctl for device 52022 ghc CALL write(0xc,0x80d507010,0xd06) 52022 ghc GIO fd 12 wrote 3334 bytes ""-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "-fuse-ld=gold" "-Wl,--no-as-needed" "-o" "Main" "-Wl,--gc-sections" "Main.o" "-L/home/ghc/lib/ghc-8.2.1/base-4.10.0.0" "-L/home/ghc/lib/ghc-8.2.1/integer-gmp-1.0.1.0" "-L/home/ghc/lib/ghc-8.2.1/ghc-prim-0.5.1.0" "-L/home/ghc/lib/ghc-8.2.1/rts" "/tmp/ghc52022_0/ghc_5.o" "/tmp/ghc52022_0/ghc_8.o" "-Wl,-u,base_GHCziInt_I16zh_con_info" ... 52022 ghc GIO fd 14 read 276 bytes "GNU gold (GNU Binutils 2.28) 1.14 ... # ld 52060 ghc RET kevent 1 52060 ghc CALL read(0x10,0x80d76c010,0x2000) 52060 ghc GIO fd 16 read 875 bytes "collect2 version 5.4.0 /usr/local/bin/ld -plugin /usr/local/libexec/gcc5/gcc/x86_64 -portbld-freebsd11.1/5.4.0/liblto_plugin.so -plugin- opt=/usr/local/libexec/gcc5/gcc/x86_64-portbld-free\ bsd11.1/5.4.0/lto-wrapper -plugin- opt=-fresolution=/tmp//ccIy1yIG.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-\ lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass- through=-lgcc_s --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/local\ /lib/gcc5/gcc/x86_64-portbld-freebsd11.1/5.4.0/crtbegin.o -L/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.1/5.4.0 -L/usr/local/lib/gcc5/gcc/x86_64-portbld-freeb\ sd11.1/5.4.0/../../.. --version -lgcc --as-needed -lgcc_s --no-as- needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc5/gcc/x86_64-portbld-freebs\ d11.1/5.4.0/crtend.o /usr/lib/crtn.o ... 52060 ghc RET kevent 1 52060 ghc CALL read(0xe,0x80d772010,0x2000) 52060 ghc GIO fd 14 read 269 bytes "GNU ld (GNU Binutils) 2.28 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 08:08:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 08:08:39 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.f7fb37ae756373a63f004051eda8032e@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I could be convinced by an example of the sort that SPJ alluded to, in which an instance of the form Multi X (Y a) behaves differently from (b ~ Y a) => Multi X b, It affects type inference: {{{ instance (a ~ Int) => C a instance (a ~ Bool) => C a vs instance C Int instance C Bool }}} GHC's type inference engine does not support backtracking. If it did, it could try out the former two instances one at a time, and see which one "worked". With the latter two, only one matches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 08:29:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 08:29:56 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.08e6018d13287b8eee4548649c9b6b4f@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't see in the patch where an arity check is omitted. And I'd love a Note somewhere giving examples of "Data families aren't as particular about their arity as type families are (because data families can be undersaturated)", at some relevant point in the type checker. The point is, I guess, that {{{ data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True }}} and {{{ data instance Sing (a :: Bool) :: Type where SFalse :: Sing False STrue :: Sing True }}} are similar, but not quite the same. Moreover, different instances can make different choices. Moreover you can't to that for type families. We should call that out somewhere, and explain why it's different (data families can be decomposed, type families can't). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 08:30:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 08:30:10 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.fc33e05772add96acd157b8d1ca3845b@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 09:05:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 09:05:43 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.de2d31bec205f9a7305227da3851b4e5@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > one would intuitively expect the language to recognize the fact that MkFun args Type does in fact expand to something which ends in Type Would one? That requires somewhat sophisticated reasoning about `MkFun` doesn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 09:16:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 09:16:46 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.a15b690c6bd802c62605145de2e478a8@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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 simonpj): Yes, that's what I've been trying to say too. If you want a name you can mention outside TH, use `mkName :: String -> Name`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 10:06:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 10:06:02 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.57f101fc9057821404f872de57239e75@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13540 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by MikolajKonarski): * related: => #13540 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 10:06:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 10:06:24 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 In-Reply-To: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> References: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> Message-ID: <061.3d7b846de2cbdf2576b1404016566739@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8949 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #8949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 10:23:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 10:23:42 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.8f4068c649ee7d8569fa48b1a8e335ac@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I can't reproduce this. I didn't use Criterion; I just ran the programs. Both produced the same code with ghc-8.0 and HEAD, and both ran equally fast. Interestingly, HEAD ran them 25% faster than 8.0. The Core looks the same, so I don't know where that improvement comes from, but I'm sure it'll make you happy. Can anyone else reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 10:44:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 10:44:09 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.5ae137d75b1332b49066ae3fb2bf0ebf@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Let's do one thing at a time. My brain is too small to accommodate all these variations. I'll commit my `-XStrict` fix. You can try it out. If you are happy, close the ticket; if not, can you give a new repro case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 11:18:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 11:18:11 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.1d64934ac2cead2076eff59a454c5dc4@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 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 AntC): Replying to [comment:3 zaoqi]: > Reflection The approach in ticket:14004#comment:8 uses reflection. In the code, the line: {{{ | Just HRefl <- ra `eqTypeRep` rb = a == b }}} For `Just HRefl`, the `Refl` is reflection. (Defined in base library `Data.Type.Equality`) This is advanced Haskell. It is very unlikely you need this. Your questions are at beginner level, so it would not help you to just copy the code. You have not explained why you cannot change the definition of `Dyn`. I have put out a request for some Chinese speaking Haskellers to try to help you. I hope they will contact you soon. (Apologies to the GHC team in advance: you might see Chinese text on this ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 11:26:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 11:26:07 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 In-Reply-To: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> References: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> Message-ID: <061.6a89e8d71a873dc8a2cdc5d3669d4a6a@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8949 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Just want to point out that neither the linux elf nor Windows GHCi linkers (non-dynamic way) currently honor section alignment. so using SSE2 more aggressively would likely cause issues here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:32:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:32:45 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.058b3dcd3445d43dc01f8059b7aae94c@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c6d4219ae46cddd63aa2b5762efaf99f815009a4/ghc" c6d4219a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6d4219ae46cddd63aa2b5762efaf99f815009a4" Clarify comment about data family arities as requested in #14045. [skip ci] comments only }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:34:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:34:12 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.7b7c3c902bf4169c48bfeb8d1f016c3d@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Does that do it? It's all in `Note [Arity of data families]` in FamInstEnv. Also, the skipped arity check in the previous patch is in `tc_fam_ty_pats` in TcTyClsDecls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:37:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:37:07 -0000 Subject: [GHC] #14035: Weird performance results. In-Reply-To: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> References: <046.b5ec9a4820990e6a06a4908d2307b2d4@haskell.org> Message-ID: <061.648b0005de48a705e5b2dff52cffb713@haskell.org> #14035: Weird performance results. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"46368868dc85fc7f0c95fe88af892ad850ed7bc6/ghc" 4636886/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46368868dc85fc7f0c95fe88af892ad850ed7bc6" Improve the desugaring of -XStrict Trac #14035 showed that -XStrict was generating some TERRIBLE desugarings, espcially for bindings with INLINE pragmas. Reason: with -XStrict, all AbsBinds (even for non-recursive functions) went via the general-case deguaring for AbsBinds, namely "generate a tuple and select from it", even though in this case there was only one variable in the tuple. And that in turn interacts terribly badly with INLINE pragmas. This patch cleans things up: * I killed off AbsBindsSig completely, in favour of a boolean flag abs_sig in AbsBinds. See Note [The abs_sig field of AbsBinds] This allowed me to delete lots of code; and instance-method declarations can enjoy the benefits too. (They could have before, but no one had changed them to use AbsBindsSig.) * I refactored all the AbsBinds handling in DsBinds into a new function DsBinds.dsAbsBinds. This allowed me to handle the strict case uniformly }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:37:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:37:07 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.c8b38113185dbef05686e8e6d5fc15bf@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: fixed | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7f2dee8e5de5dbc09a7fb66ec54fd41ab4b1b2eb/ghc" 7f2dee8e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f2dee8e5de5dbc09a7fb66ec54fd41ab4b1b2eb" Remove redundant goop See comment:22 in Trac #13594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:37:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:37:07 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.f5ad287088688cfc2feb5b479f1b749e@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: fixed | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"af89d6872da2e00be738e1ac541346cd84e6d141/ghc" af89d68/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af89d6872da2e00be738e1ac541346cd84e6d141" Reject top-level banged bindings Bizarrely, we were not rejecting !x = e Fix: * In the test in DsBinds.dsTopLHsBinds, use isBangedHsBind, not isBangedPatBind. (Indeed the latter dies altogther.) * Implement isBangedHsBind in HsUtils; be sure to handle AbsBinds All this was shown up by Trac #13594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:40:20 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.d2cc4d632b6994204a6266371bbfde21@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I thought of the same problem (comment:10) afterward, too. But regardless, we could require that the ending kind is `Type` at all usage sites, instead of at the definition site. Indeed, I wonder if we can just omit the check entirely, as long as we check the types of data constructors. Those types end in `-> T blah blah blah`, so if `T blah blah blah`'s kind is other than `Type`, the data constructor type will fail to kind-check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:47:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:47:00 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.6db639e3249aefc3663315b938dfe248@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: fixed | RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I fixed both comment:22 and the wrongly-accepted program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:47:40 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.4389affa7c72083a1d100a6112555b6b@haskell.org> #14024: typechecker tests T13594 T13822 tc269 failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I've fixed the #13594 panic. That leaves the #13822 one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:48:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:48:25 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.53941cebd117c40dac6afef8e45c412e@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: #13643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Does this patch fix the panic in #14024? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 12:59:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 12:59:28 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.24179b3e844b170225b7b468a7367d63@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > I wonder if we can just omit the check entirely, as long as we check the types of data constructors Ah yes, that sounds more plausible. And now the whole thing makes more sense. Even today with {{{ data family T a :: * data instance T Int = T1 Bool }}} we desugar to a new type constructor `TInt :: *`, declared thus {{{ data TInt = T1 Bool axiom ax1 :: TInt ~R T Int }}} and occurrences of the original user data constructor `T1` is converted to occurrences of the wrapper {{{ $WT1 :: Bool -> T Int $WT1 x = T1 x |> ax1 }}} Now I suppose that if we instead had {{{ data family T a :: F a -- For some type family F }}} (which is what Ryan suggests), and we can prove `co :: F Int ~ *`, then perhaps we'd get {{{ axiom ax1 :: (TInt :: *) ~R ((T Int |> co) :: *) }}} or something like that? In other words, we relax the checks on the data ''family'' but add checks on the data ''constructors'', including putting the extra proof (e.g. `co :: F Int ~ *` in somewhere. I'm not sure of the details, but there is enough desugaring around data families and their data instances that it looks entirely possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:00:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:00:13 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.2b2939faceb2bebf103ee3dcb3bc61d2@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T9020 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D851 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): What's it going to take to put this to bed? It sounds like comment:6 suggests there may still be something to be done despite the early inline patch? It's not clear to me just what. For the record, this test case no longer seems to be in the test suite, but compiling something similar dropped from 5.5s in 7.8 to 1s in 7.10 and 8.0 to 0.8s in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:08:43 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.6b750bab82ee7ea678406b92ed4ad6b1@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah I missed the reference to `Note [Arity of data families]`. Thanks. But {{{ This instance is very nearly equivalent to data instance Sing (a :: Bool) where ... but without the last pattern, we have an under-saturated data family instance. On its own, this example is not compelling }}} Can you say more precisely what /is/ the difference? Is it only the newtype-eta thing? Or is there anything else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:12:34 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.c4d87436a74f5d55251c71486ffd8b99@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T9020 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D851 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If it's good in HEAD, let's add a regression test and declare victory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:18:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:18:34 -0000 Subject: [GHC] #14065: Type inference In-Reply-To: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> References: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> Message-ID: <059.2755e697b64b748bbe6c39d815511472@haskell.org> #14065: Type inference -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (Type checker) Comment: I believe this is behaving as expected. GADTs will in general require that you provide more type annotations than pure Haskell 98. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:32:56 -0000 Subject: [GHC] #13817: Simplifier and SpecConstr performance regression with 8.2.1 In-Reply-To: <047.0d86e1522b2fc42732f7ab726cf6825d@haskell.org> References: <047.0d86e1522b2fc42732f7ab726cf6825d@haskell.org> Message-ID: <062.49bfc8d59834891af71ec7d16ed76e7d@haskell.org> #13817: Simplifier and SpecConstr performance regression with 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => infoneeded Old description: > A propietary application I've upgraded to compile with 8.2.1-rc1 makes > GHC manifest a performance regression when producing optimized > ({{{-O2}}}) code. > > After a crude analysis of a compile log produced with {{{-show-passes}}} > it appears that the biggest slowdown is in the Simplifier and SpecConstr > phases when compiling the "main" modules. > > Theres a conversation at GHC Users with more details: > https://mail.haskell.org/pipermail/glasgow-haskell- > users/2017-June/026543.html. The data, the results and the script to to > analyse it live at: > https://gist.github.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e > > I'll try to update this ticket with a way to to reproduce it as soon as I > can (if I can) New description: A proprietary application I've upgraded to compile with 8.2.1-rc1 makes GHC manifest a performance regression when producing optimized ({{{-O2}}}) code. After a crude analysis of a compile log produced with {{{-show-passes}}} it appears that the biggest slowdown is in the Simplifier and SpecConstr phases when compiling the "main" modules. Theres a conversation at GHC Users with more details: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-June/026543.html. The data, the results and the script to to analyse it live at: https://gist.github.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e I'll try to update this ticket with a way to to reproduce it as soon as I can (if I can). -- Comment: I don't think we can do anything about this without a proper reproduction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:50:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:50:42 -0000 Subject: [GHC] #14058: Cannot bundle pattern synonym with exported data family In-Reply-To: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> References: <050.52ea1fb9647e0f7d1278d291bc787848@haskell.org> Message-ID: <065.4c3055f34fa06fb0f1cce86b80787af0@haskell.org> #14058: Cannot bundle pattern synonym with exported data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3808 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3808 Comment: I think this turns out to be a surprisingly simple fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:53:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:53:04 -0000 Subject: [GHC] #14056: Figure out what to do about libffi In-Reply-To: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> References: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> Message-ID: <061.8bcef001ab68a5c22651649d342b9004@haskell.org> #14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): For the record, angerman requested a new release from upstream in March. See https://github.com/libffi/libffi/issues/296. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:57:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:57:31 -0000 Subject: [GHC] #14056: Figure out what to do about libffi In-Reply-To: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> References: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> Message-ID: <061.2a43d4cd7c28ec58fa38a569d57c5b9b@haskell.org> #14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): [[https://www.gnu.org/software/libffcall/|libffcall]] is an alternative that the [[https://github.com/ocamllabs/ocaml-ctypes/issues/56|Caml]] folks have considered, but they also decided against it due to lack of maintenance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 13:59:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 13:59:37 -0000 Subject: [GHC] #14056: Figure out what to do about libffi In-Reply-To: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> References: <046.2f5998c0c0f3e8ceedb396a3922fff3a@haskell.org> Message-ID: <061.f3d9fa8a888fade1fd0abdba8bdedaf8@haskell.org> #14056: Figure out what to do about libffi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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 bgamari): [[http://www.dyncall.org/|dyncall]] is another. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:02:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:02:13 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.9eef54fe3c6bd7bc66aed0647c07f72e@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mpickering (added) Comment: Here's one architectural issue: `COMPLETE` sets currently aren't designed with data family instances in mind. Why? Because you can optionally give the name of a tycon for a `COMPLETE` set, e.g., {{{#!hs {-# COMPLETE False, TooGoodToBeTrue :: Boolean #-} }}} However, this necessarily needs to be more involved for data family instances, because we're dealing with a proper type, not just a tycon. Put differently, it wouldn't be enough to say: {{{#!hs {-# COMPLETE SFalse, STrue :: Sing #-} }}} This is wrong, since we don't want a `COMPLETE` set for `Sing (a :: k)`, we want a `COMPLETE` set for `Sing (a :: Bool)`. But GHC won't let us use: {{{#!hs {-# COMPLETE SFalse, STrue :: Sing (z :: Bool) #-} }}} {{{ Bug.hs:20:47: error: parse error on input ‘(’ | 20 | {-# COMPLETE SFalse, STooGoodToBeTrue :: Sing (z :: Bool) #-} | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:03:00 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.0a02e66d220ed463cc6666eeb598212d@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 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 bgamari): Quite alright! I wish I could do more to help but my Chinese skills are quite non-existent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:03:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:03:38 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.c7ea6f485e74ed2df8913ab4a672afc4@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 inaki): I am starting to receive bug reports for the packages I maintain (these are the bindings for gtk and other libraries autogenerated by http://github.com/haskell-gi/haskell-gi) from people running into this issue. Is there some workaround I could apply to avoid the panic? I would be happy to help fixing the bug properly, of course, but I have not clue where to start, and that would in any case not help for the crashes with the already released 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:10:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:10:25 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.06e067f1feaf830ce8f4067bdf1d4347@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 ezyang): For reference, the ticket is https://github.com/haskell-gi/haskell- gi/issues/113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:13:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:13:01 -0000 Subject: [GHC] #14042: Datatypes cannot use a type family in their return kind In-Reply-To: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> References: <050.9a18856b2826cce2f7fbd06d0b9d2dd1@haskell.org> Message-ID: <065.2474b090b4b4c0d001db3ea08cb23994@haskell.org> #14042: Datatypes cannot use a type family in their return kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This ticket is actually about regular old datatypes, not data families. Let's solve the datatype problem first, I think. The only part I haven't quite figured out is if we need the coercion relating the declared return kind to `Type` somewhere, but I don't see where it would go, other than the types of constructors. What would the constructor workers look like? I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:13:25 -0000 Subject: [GHC] #14065: Type inference In-Reply-To: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> References: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> Message-ID: <059.4d8ecd7df91b1487bcc142fc507389e6@haskell.org> #14065: Type inference -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:17:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:17:05 -0000 Subject: [GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary In-Reply-To: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> References: <050.63727aea9fb31cf6413bb2ae1492c1a3@haskell.org> Message-ID: <065.7aaefce446bb0cc867f89985a0909fc1@haskell.org> #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There isn't a difference. {{{#!hs data instance Sing (a :: Bool) where ... }}} and {{{#!hs data instance Sing :: Bool -> Type where ... }}} compile to precisely the same internal representation. It's the same because the first one gets eta-reduced to look like the second. That's why the note says {{{ This instance is equivalent to `data instance Sing (a :: Bool)` }}} I'm not sure where you get "very nearly equivalent" above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:17:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:17:05 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.9153269f6063300f403c0890dd7c9072@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 ezyang): I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful. Does haskell-gi define type families? If it doesn't, this particular issue is unlikely to be the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:21:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:21:44 -0000 Subject: [GHC] #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite In-Reply-To: <045.7ecb20ffade767f887f3581e5bd15ca2@haskell.org> References: <045.7ecb20ffade767f887f3581e5bd15ca2@haskell.org> Message-ID: <060.d6e9486074bdca2e7ffd8b6851020725@haskell.org> #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I don't think the warning, per se, indicates much. However, there are definitely some strange things going on with these types. Lots of type- level recursion. I had hoped that the fix for the specializer generating loopy code might have done something good here, but as far as I can tell this is still an issue in the released 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:30:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:30:14 -0000 Subject: [GHC] #13283: T5435_dyn_asm fails with gold linker In-Reply-To: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> References: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> Message-ID: <062.d6a3f8adb395dd58c2af355cabb503cb@haskell.org> #13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13883 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #13883 Comment: This is a duplicate of #13883. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 14:32:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 14:32:29 -0000 Subject: [GHC] #12878: Use gold linker by default if available on ELF systems In-Reply-To: <047.c7ddb643b4ab18bdba2072ff5764699e@haskell.org> References: <047.c7ddb643b4ab18bdba2072ff5764699e@haskell.org> Message-ID: <062.7cf47bf7bea4b5ba4263a87681418b14@haskell.org> #12878: Use gold linker by default if available on ELF systems -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This was fixed in #13541. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:18:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:18:40 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.010fccebc9341843c5985a9c17723933@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: (none) => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:40:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:40:46 -0000 Subject: [GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS In-Reply-To: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> References: <045.676ceb519415dbe369d9afa9e2e3df99@haskell.org> Message-ID: <060.82a42ce37ca6c555a688f7954095e0d0@haskell.org> #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: hs-boot 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 inaki): Replying to [comment:11 ezyang]: > I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful. OK, I'll give it a try again, now that I have a better idea of what's going on. > Does haskell-gi define type families? If it doesn't, this particular issue is unlikely to be the problem. Yes, it uses them extensively. In fact, if I remove the type-family related code the issue disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:46:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:46:01 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 In-Reply-To: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> References: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> Message-ID: <061.e8fcba403744dbfaef49f65870ea0227@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8949 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Indeed this is a duplicate of #8949. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:46:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:46:47 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.65e482695a0ffa2092fb78ac07e74294@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13540 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by bgamari): Phyx points out in ticket:13540#comment:4 that, > neither the linux elf nor Windows GHCi linkers (non-dynamic way) currently honor section alignment. so using SSE2 more aggressively would likely cause issues here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:55:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:55:31 -0000 Subject: [GHC] #14065: Type inference In-Reply-To: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> References: <044.a460e43895a6e72446418fd2fb51744e@haskell.org> Message-ID: <059.900dea8e151b6467a13d6d95dd3e2cd2@haskell.org> #14065: Type inference -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: invalid | 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 bgamari): To clarify, I've confirmed with Simon that this is indeed the expected behavior. The typechecker is conservative in inferring underneath pattern matches on equalities. See Chapter 6 of the [[http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints /jfp-outsidein.pdf|OutsideIn paper]] to see the complications that arise when you try to infer under such matches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:57:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:57:37 -0000 Subject: [GHC] #12176: Failure of bidirectional type inference at the kind level In-Reply-To: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> References: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> Message-ID: <062.79ebabf664026c6fb1e43cf0a8d6bef0@haskell.org> #12176: Failure of bidirectional type inference at the kind level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12176 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.4.1 Old description: > I'm feeling particularly sadistic towards GHC at the moment, and so I fed > it this: > > {{{ > import Data.Kind > > data Proxy :: forall k. k -> Type where > MkProxy :: forall k (a :: k). Proxy a > > data X where > MkX :: forall (k :: Type) (a :: k). Proxy a -> X > > type Expr = (MkX :: forall (a :: Bool). Proxy a -> X) > > type family Foo (x :: forall (a :: k). Proxy a -> X) where > Foo (MkX :: forall (a :: k). Proxy a -> X) = (MkProxy :: Proxy k) > }}} > > Incredibly, GHC accepts it! And it even means what I wish it to, with > GHCi telling me the following (with `-fprint-explicit-kinds`): > > {{{ > λ> :i Foo > type family Foo k (x :: forall (a :: k). Proxy k a -> X) > :: Proxy * k > where [k] Foo k ('MkX k) = 'MkProxy * k > }}} > > That is, I wished to extract the kind parameter to `MkK`, matching > against a partially-applied `MkX`, and GHC understood that intention. > > However, sadly, writing `Foo Expr` produces > > {{{ > • Expected kind ‘forall (a :: k0). Proxy k0 a -> X’, > but ‘Expr a0’ has kind ‘Proxy Bool a0 -> X’ > • In the first argument of ‘Foo’, namely ‘Expr’ > In the type ‘Foo Expr’ > In the type family declaration for ‘XXX’ > }}} > > For some reason, `Expr` is getting instantiated when it shouldn't be. > > Perhaps there's a simpler test case demonstrating the bug, but I feel so > gleeful that this chicanery is accepted at all that I wanted to post. New description: I'm feeling particularly sadistic towards GHC at the moment, and so I fed it this: {{{#!hs import Data.Kind data Proxy :: forall k. k -> Type where MkProxy :: forall k (a :: k). Proxy a data X where MkX :: forall (k :: Type) (a :: k). Proxy a -> X type Expr = (MkX :: forall (a :: Bool). Proxy a -> X) type family Foo (x :: forall (a :: k). Proxy a -> X) where Foo (MkX :: forall (a :: k). Proxy a -> X) = (MkProxy :: Proxy k) }}} Incredibly, GHC accepts it! And it even means what I wish it to, with GHCi telling me the following (with `-fprint-explicit-kinds`): {{{ λ> :i Foo type family Foo k (x :: forall (a :: k). Proxy k a -> X) :: Proxy * k where [k] Foo k ('MkX k) = 'MkProxy * k }}} That is, I wished to extract the kind parameter to `MkK`, matching against a partially-applied `MkX`, and GHC understood that intention. However, sadly, writing `Foo Expr` produces {{{ • Expected kind ‘forall (a :: k0). Proxy k0 a -> X’, but ‘Expr a0’ has kind ‘Proxy Bool a0 -> X’ • In the first argument of ‘Foo’, namely ‘Expr’ In the type ‘Foo Expr’ In the type family declaration for ‘XXX’ }}} For some reason, `Expr` is getting instantiated when it shouldn't be. Perhaps there's a simpler test case demonstrating the bug, but I feel so gleeful that this chicanery is accepted at all that I wanted to post. -- Comment: Given that this isn't a regression of 8.2 I'm going to punt this off until 8.4.1 unless someone objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 15:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 15:58:30 -0000 Subject: [GHC] #11995: Can't infer type In-Reply-To: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> References: <051.ecd85ed869df953db3456994d5047fa3@haskell.org> Message-ID: <066.6ad9ab1eb2bb93e2083ec15d79df7c04@haskell.org> #11995: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.2 Comment: Merged to `ghc-8.2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 16:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 16:39:56 -0000 Subject: [GHC] #14066: Skolem escape at the kind level Message-ID: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- This program should be rejected {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE KindSignatures #-} module Foo2 where import Data.Kind ( Type ) import Data.Type.Equality import Data.Proxy import GHC.Exts data SameKind :: k -> k -> Type f (x :: Proxy a) = let g :: forall k (b :: k). SameKind a b g = undefined in () }}} But * 8.0 rejects it, with an unhelpful message * 8.2 accepts it, and the result satisfies Core Lint * HEAD accepts it, and produces a Core Lint Error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 16:40:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 16:40:44 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.8d4cc790a5cf6769bd2d06eead6f11f8@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > This program should be rejected > {{{ > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE TypeInType #-} > {-# LANGUAGE KindSignatures #-} > > module Foo2 where > > import Data.Kind ( Type ) > > import Data.Type.Equality > > import Data.Proxy > > import GHC.Exts > > > data SameKind :: k -> k -> Type > > > f (x :: Proxy a) = let g :: forall k (b :: k). SameKind a b > > g = undefined > > in > > () > }}} > But > > * 8.0 rejects it, with an unhelpful message > > * 8.2 accepts it, and the result satisfies Core Lint > > * HEAD accepts it, and produces a Core Lint Error New description: This program should be rejected {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE KindSignatures #-} module Foo2 where import Data.Kind ( Type ) import Data.Type.Equality import Data.Proxy import GHC.Exts data SameKind :: k -> k -> Type f (x :: Proxy a) = let g :: forall k (b :: k). SameKind a b g = undefined in () }}} But * 8.0 rejects it, with an unhelpful message * 8.2 accepts it, and the result satisfies Core Lint * HEAD accepts it, and produces a Core Lint Error -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 16:41:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 16:41:29 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.d3f85db49bc53920a10d6d8bffbccde6@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Probable cause: need an implication constraint in `tcExplicitTkBndrs` and similarly `Implicit`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 16:45:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 16:45:02 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.f447399f075b3d1f963f74bda89fa65f@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Fixing this will probably cure #14040. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:02:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:02:05 -0000 Subject: [GHC] #14067: Static Argument Transformation for tail-recursive functions Message-ID: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> #14067: Static Argument Transformation for tail-recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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: -------------------------------------+------------------------------------- In #13966 it was determined that having a variant of the Static Argument Transformation (StaticArgumentTransformation) pass that would specifically look for tail-recursive functions, and turn them into recursive join points, would be beneficial. This ticket tracks this task. Consider {{{ f x y = case y of A -> f x y' B -> e2 C -> e3 }}} Here the first argument to f is "static"; that is, the same in every call. So we can transform like this {{{ f x y = joinrec $j y = case y of A -> $j y' B -> e2 C -> e3 in $j y }}} Note that `x` isn't passed around in every iteration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:02:23 -0000 Subject: [GHC] #14067: Static Argument Transformation for tail-recursive functions In-Reply-To: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> References: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> Message-ID: <061.a2b951fab44c60163c07a8addef44a50@haskell.org> #14067: Static Argument Transformation for tail-recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:03:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:03:31 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.5d395f074bce58833610694fd65749a5@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #14067 Comment: This ticket is confusing, and about a specific use case. I took the liberty of creating a new ticket for the task of implementing a SAT for tail-recursive functions at #14067. Once that is done, we can revisit if it actually fixed the problem at hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:05:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:05:18 -0000 Subject: [GHC] #14061: reflection In-Reply-To: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> References: <044.a538367cb8f50c362f6a4ae142a8bfce@haskell.org> Message-ID: <059.0f65b0d086edbdbcc5f67fa60c81bec6@haskell.org> #14061: reflection -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 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 winter): 对于帮助类的问题，还请使用 Haskell-cafe 邮件组（对于初学者相当友好）。或者 去知乎、segmentfault这样的网站（尤其是中文类的问题），Ghc trac主要是用来反 馈 bug 或者提出特性需求的，所以如果你还是认为 GHC 存在 bug 的话，请解释你 希望你的程序做什么，仅仅贴出代码的话我们很难给出解释，于是你也会很难理解。 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:05:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:05:50 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA0Njog4oCcSWxsZWdhbCB0eXBlIHN5bm9u?= =?utf-8?q?ym_family_application_in_instance=E2=80=9D_is_too_stri?= =?utf-8?q?ct_in_the_presence_of_functional_dependencies?= In-Reply-To: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> References: <050.4d1e728054f90074ed56a1d263e8a47d@haskell.org> Message-ID: <065.436b7194a541c3d1adc0bdc5648729ed@haskell.org> #14046: “Illegal type synonym family application in instance” is too strict in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3485 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): > It affects type inference: [snip] Yes, I’m aware of that, but my impression was that the functional dependency changes that. Multiple instances where the only thing that changes is variables constrained by a functional dependency are illegal, ''anyway''. Therefore, I’m trying to understand if there’s some difference between these two: {{{#!hs class C a b | a -> b instance C (Maybe a) [a] }}} vs {{{#!hs class C a b | a -> b instance (b ~ [a]) => C (Maybe a) b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:16:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:16:03 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.1d8c8ec62b5550a82e28619409282d32@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Hmm, maybe I did that a bit prematurely, without fully understanding what we should be doing. Upon closer reading, there are two tasks: * Transforming a tail-recursive function into a non-recursive function with a `joinrec`. * SAT for tail-recursive functions It seems that the first is independent of the second, and if the first one was done, one can rephrase the second as “SAT for `joinrec`s”. Is that roughly correct? (I am surprised that the former is not done already from the beginning of join points in GHC. But a brief look at the distribution of labor between OccAnal and the Simplifier makes it clear to me that this change is not trivial.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:18:21 -0000 Subject: [GHC] #14067: Static Argument Transformation for tail-recursive functions In-Reply-To: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> References: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> Message-ID: <061.707b375c286cf446e90a52c8295674e8@haskell.org> #14067: Static Argument Transformation for tail-recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > In #13966 it was determined that having a variant of the Static Argument > Transformation (StaticArgumentTransformation) pass that would > specifically look for tail-recursive functions, and turn them into > recursive join points, would be beneficial. This ticket tracks this task. > > Consider > > {{{ > f x y = case y of > A -> f x y' > B -> e2 > C -> e3 > }}} > > Here the first argument to f is "static"; that is, the same in every > call. So we can transform like this > > {{{ > f x y = joinrec $j y = case y of > A -> $j y' > B -> e2 > C -> e3 > in $j y > > }}} > > Note that `x` isn't passed around in every iteration. New description: In #13966 it was determined that having a variant of the Static Argument Transformation (StaticArgumentTransformation) pass that would specifically work on recursive join points, would be beneficial. This ticket tracks this task. Consider {{{ joinrec $j x y = case y of A -> $j x y' B -> e2 x C -> e3 in $j foo bar }}} Here the first argument to `$j` is "static"; that is, the same in every call. So we can transform like this {{{ joinrec $j y = case y of A -> $j y' B -> e2 foo C -> e3 in $j bar }}} Note that `x` isn't passed around in every iteration any more. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:21:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:21:15 -0000 Subject: [GHC] #14068: Turn tail-recursive functions into recursive jointpoints Message-ID: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> #14068: Turn tail-recursive functions into recursive jointpoints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. This came up in #13966, and might go well with #14067. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:21:41 -0000 Subject: [GHC] #14068: Turn tail-recursive functions into recursive jointpoints In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.d15b326947dd34a31dba489f5b73d317@haskell.org> #14068: Turn tail-recursive functions into recursive jointpoints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => mpickering * related: => #13966 #14067 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:22:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:22:37 -0000 Subject: [GHC] #14067: Static Argument Transformation for tail-recursive functions In-Reply-To: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> References: <046.5dc705648434dedd02006c4f3262b7e6@haskell.org> Message-ID: <061.0e7ecfa4d2eb7fb0da4949711edc2508@haskell.org> #14067: Static Argument Transformation for tail-recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => JoinPoints Comment: Also see: #14068 Turn tail-recursive functions into recursive joinpoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:23:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:23:08 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.07a9c842bef6cc772e4247234b333a7f@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: #14067 => #14067 #14068 Comment: See #14068 for the first of these tasks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:44:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:44:52 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.6d006c37d0effeb3d9ea226a56312f7c@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: (none) => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 17:54:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 17:54:37 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.d60579d332e35042cf54a9bc4558f2eb@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by phadej): In GHC-8.2.1 and GHC-8.0.2 maximum residency is the same, but 8.2.1 makes GHC work hard. I don't have a profiled build at my hand right now to see what's is so much created there === GHC 8.2.1 {{{ *Foo> :q Leaving GHCi. 117,933,393,408 bytes allocated in the heap 8,146,416,328 bytes copied during GC 19,708,480 bytes maximum residency (254 sample(s)) 281,520 bytes maximum slop 50 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 30416 colls, 0 par 14.994s 14.949s 0.0005s 0.0330s Gen 1 254 colls, 0 par 0.134s 0.137s 0.0005s 0.0033s TASKS: 5 (1 bound, 4 peak workers (4 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.002s ( 0.001s elapsed) MUT time 36.655s ( 39.458s elapsed) GC time 15.128s ( 15.085s elapsed) EXIT time 0.036s ( 0.046s elapsed) Total time 51.820s ( 54.591s elapsed) Alloc rate 3,217,432,136 bytes per MUT second Productivity 70.8% of total user, 72.4% of total elapsed }}} === GHC 8.0.2 {{{ *Foo> :q Leaving GHCi. 2,025,372,528 bytes allocated in the heap 67,188,040 bytes copied during GC 19,710,096 bytes maximum residency (8 sample(s)) 480,376 bytes maximum slop 44 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 612 colls, 0 par 0.161s 0.160s 0.0003s 0.0023s Gen 1 8 colls, 0 par 0.149s 0.150s 0.0187s 0.0415s TASKS: 5 (1 bound, 4 peak workers (4 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 3.144s ( 8.657s elapsed) GC time 0.310s ( 0.310s elapsed) EXIT time 0.042s ( 0.042s elapsed) Total time 3.546s ( 9.010s elapsed) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 18:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 18:54:39 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.48c624fc3d4425eb11e7465f9e7f41c3@haskell.org> #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 bgamari): What is the status of this, akio? > I wonder if this improvement justifies the added complexity to the compiler (about 400 lines of code added under `compiler/`). Right now I don't see any way to make the analysis/transformation more effective. Well, 2.6% improvement in runtime is quite sizeable. This sounds quite worthwhile to me. Good work! Simon, do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 19:22:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 19:22:53 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.fe87e550ef5fda24f74d61f60286a65e@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, this is quite odd; I have no such problem while compiling `lens` with `-fuse-ld=gold` on FreeBSD 11.0 (amd64) (although with gcc 4.8.5), {{{ $ freebsd-version 11.0-RELEASE-p1 $ pkg info gcc-4.8.5_2 GNU Compiler Collection 4.8 libiconv-1.14_9 Character set conversion library gmp-5.1.3_3 Free library for arbitrary precision arithmetic binutils-2.27_4,1 GNU binary tools ... $ ghc -V The Glorious Glasgow Haskell Compilation System, version 8.2.1 $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags"," -std=gnu99 -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","NO") ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 19:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 19:41:52 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.49c004dc05f9254ff21be80a0a7f6e64@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): ak3n:I have a mostly complete patch already on phab which you might want to fi nish off and refine. https://phabricator.haskell.org/D3566 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 20:23:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 20:23:57 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.6d8bde3b6f010a235eca801b7d25973a@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is [https://github.com/ghc-proposals/ghc- proposals/pull/32#issuecomment-319175473 Type v Constraint] not a use case, {{{#!hs data family (=>) data instance (=>) :: forall (r :: RuntimeRep). Constraint -> TYPE r -> Type data instance (=>) :: Constraint -> Constraint -> Constraint data instance (=>) :: forall (r :: RuntimeRep). TYPE r -> Constraint -> Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 21:33:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 21:33:35 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.a13452bb90f0475bcc22215eefba6a3b@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by phadej): * Attachment "with-m.prof" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 21:33:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 21:33:48 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.5ed739b8987f69fe059bbbc24aa5b552@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by phadej): * Attachment "without-m.prof" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 21:40:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 21:40:46 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.9260599b8902cbdca9c597dbc837ad38@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by phadej): I added two time profiles, running the variants of ryan's test-case, with and without ":m *Foo". They look similar, but in bad behaviour withCleanupSession does something, which takes half of the time. {{{ individual inherited COST CENTRE MODULE no. entries %time %alloc WITH :m *Foo, BAD behaviour withCleanupSession GHC 1501 1 50.2 90.2 99.9 99.9 hscStmtWithLocation HscMain 2406 1201 0.0 0.0 16.5 9.4 hscParseStmtWithLocation HscMain 2407 1201 0.0 0.0 0.1 0.1 hscParseThingWithLocation HscMain 2408 1201 0.0 0.0 0.1 0.1 Parser HscMain 2409 1201 0.1 0.1 0.1 0.1 logWarningsReportErrors HscMain 2410 1201 0.0 0.0 0.0 0.0 logWarnings HscMain 2411 1201 0.0 0.0 0.0 0.0 hscParsedStmt HscMain 2412 1201 1.4 1.7 16.4 9.3 ioMsgMaybe HscMain 2413 2402 8.7 4.3 10.9 5.2 Digraph.topSort Digraph 2414 7508 0.0 0.0 0.0 0.0 solveSimples TcInteract 2424 6307 0.1 0.0 2.0 0.9 solve_loop TcInteract 2426 0 1.5 0.7 1.9 0.9 canEvVar TcCanonical 2427 8108 0.4 0.2 0.4 0.2 canClass TcCanonical 2428 901 0.0 0.0 0.0 0.0 WITHOUT :m *Foo, GOOD behaviour withCleanupSession GHC 1501 1 6.4 16.8 99.8 99.3 hscStmtWithLocation HscMain 2406 1201 0.0 0.0 30.9 81.2 hscParseStmtWithLocation HscMain 2407 1201 0.0 0.0 0.3 1.0 hscParseThingWithLocation HscMain 2408 1201 0.0 0.0 0.3 1.0 Parser HscMain 2409 1201 0.3 0.9 0.3 0.9 logWarningsReportErrors HscMain 2410 1201 0.0 0.0 0.0 0.0 logWarnings HscMain 2411 1201 0.0 0.0 0.0 0.0 hscParsedStmt HscMain 2412 1201 2.8 14.4 30.5 80.2 ioMsgMaybe HscMain 2413 2402 16.3 37.2 20.2 45.2 Digraph.topSort Digraph 2414 7508 0.0 0.1 0.0 0.1 solveSimples TcInteract 2424 6307 0.2 0.1 3.6 7.6 solve_loop TcInteract 2426 0 2.7 5.7 3.4 7.5 canEvVar TcCanonical 2427 8108 0.8 1.7 0.8 1.7 canClass TcCanonical 2428 901 0.0 0.1 0.0 0.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:02:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:02:24 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.c1958c0f689046fb964ae2e2324f7de6@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker 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 bgamari): Fixing this will unblock #8949. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:05:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:05:12 -0000 Subject: [GHC] #14069: RTS linker maps code as writable Message-ID: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- GHC's RTS linker maps executable code in writable pages, representing a significant potential exploit point for arbitrary code execution. OpenBSD disallows running program that do this by default. Fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:05:42 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.c2873b428d3b0fab9087b2dd020fc558@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker 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 bgamari): I've opened #14069 to fix the protection bits issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:08:25 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.0359eab2347d8506950d8490fcf7459a@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > GHC's RTS linker maps executable code in writable pages, representing a > significant potential exploit point for arbitrary code execution. OpenBSD > disallows running program that do this by default. > > Fix this. New description: GHC's RTS linker maps executable code in writable pages, representing a significant potential exploit point for arbitrary code execution. OpenBSD disallows running program that do this by default. Instead we should first map pages as `PROT_READ | PROT_WRITE`, perform any necessary relocations (which requires writing), and then `mprotect` it to `PROT_READ | PROT_EXEC`. To find the relevant code grep for `PROT_EXEC` in the `rts/` directory. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:11:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:11:01 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.354326ddf9f21d774f6cbe2f0c6690a1@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: romanzolotarev (added) Comment: CCing romanzolotarev who expressed interest in this on Twitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 22:50:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 22:50:03 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.d7d5b62f0aa7b2a296dce7e554183ff3@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Currently we use Harbormaster to build Differentials and commits. While > this works, it leaves much to be desired, > > * job scheduling is (literally) random: this means that some patch > authors end up waiting literally ways for their patches to be built > * there is little support for automatic provisioning of builders: this > means we can't scale to meet demand and make poor use of our > computational resources > * periodic builds (e.g. nightlies) are not supported. > * it lacks a sensible interface for integration with external tools: > this means that efforts like CI-before-merge have been pushed off > * status reporting is poor: even answering the question of what a given > builder is currently working on is surprisingly difficult > * maintenance is a byzantine: Adding a new builder requires adding at > least six different objects (a Harbormaster Build Plan, a Drydock Working > Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an > Almanac Binding) in various Phabricator applications. None of this > configuration can be tracked under version control nor can most of it be > cloned from an existing builder's configuration. > * Design assumptions don't match GHC's constraints: Harbormaster was > designed under the assumption that builds are cheap and computation > plentiful. The maintainers have stated that they have little interest in > supporting environments where this doesn't hold. > > Jenkins, while far from perfect, seems a bit better suited to our needs, > more mature, and far more flexible. This ticket will serve as the > checklist for our move to Jenkins. > > In the end we want, > > * Builders (static or dynamically-provisioned, as appropriate) for > * x86-64, i386 Linux > * x86-64, i386 Windows > * x86-64 Darwin > * x86-64 OpenBSD > * Cross compile from x86-64 to ARM > * Native ARM > > * Differential builds with sensible scheduling (e.g. first build on > 64-bit Linux where machines are cheap, then build on the others) > * Per-commit builds on all > * Nightly builds on all, including > * Collection of binary distribution for user download > * Update of `master` documentation mirror on downloads.haskell.org > * Slow validation (including tests requiring Hackage packages) > * nofib run on some platforms? > * Test-before-merge-to-master New description: Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired, * job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built * there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources * periodic builds (e.g. nightlies) are not supported. * it lacks a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off * status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult * common maintenance tasks are byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration. * Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold. Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins. In the end we want, * Builders (static or dynamically-provisioned, as appropriate) for * x86-64, i386 Linux * x86-64, i386 Windows * x86-64 Darwin * x86-64 OpenBSD * Cross compile from x86-64 to ARM * Native ARM * Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others) * Per-commit builds on all * Nightly builds on all, including * Collection of binary distribution for user download * Update of `master` documentation mirror on downloads.haskell.org * Slow validation (including tests requiring Hackage packages) * nofib run on some platforms? * Test-before-merge-to-master -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 23:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 23:05:35 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.d178545366b0502684b2214d576c8d05@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by phadej): when module is loaded into context with `:m` we `InteractiveEval.setContext` which builds `ic_rn_gbl_env` with {{{ !final_rdr_env = all_env `icExtendGblRdrEnv` ic_tythings old_ic }}} Because there aren't shadowing cleanup anymore, `ic_tythings` grows, `icExtendGblRdrEnv` is linear in ic_tythings size, which causes the quadratic behaviour when we repeadetly `:m` modules. So `it` isn't related to this bug. E.g. the `GenExample.hs` version below has similar slowdown: {{{ module Main where import Control.Monad import System.Environment import System.Exit import System.IO main :: IO () main = do args <- getArgs case args of n:_ -> genExamples (read n) _ -> do hPutStrLn stderr "usage: runghc GenExamples.hs " exitWith $ ExitFailure 1 genExamples :: Int -> IO () genExamples nExamples = do putStrLn ":set +s" putStrLn ":l Foo" putStrLn "let bar = ()" -- first one sequence_ [genExample i | i <- [1..nExamples] ] genExample :: Int -> IO () genExample i = putStr $ unlines [ "" , ":m *Foo" , "let foo = bar" -- ask old , "let bar = ()" -- reset, if `let bar = foo` is even slower ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 31 23:12:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Jul 2017 23:12:57 -0000 Subject: [GHC] #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 In-Reply-To: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> References: <050.db94ecc603495ad4a4c3a0e35b8ec360@haskell.org> Message-ID: <065.4de28d1c142987ba24707df9a9dc1b5b@haskell.org> #14052: Significant GHCi speed regression with :module and `let` in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by phadej): {{{ --- a/compiler/main/InteractiveEval.hs +++ b/compiler/main/InteractiveEval.hs @@ -655,7 +655,7 @@ setContext imports liftIO $ throwGhcExceptionIO (formatError dflags mod err) Right all_env -> do { ; let old_ic = hsc_IC hsc_env - !final_rdr_env = all_env `icExtendGblRdrEnv` ic_tythings old_ic + !final_rdr_env = {-# SCC "final_rdr_env" #-} all_env `icExtendGblRdrEnv` ic_tythings old_ic ; setSession hsc_env{ hsc_IC = old_ic { ic_imports = imports , ic_rn_gbl_env = final_rdr_env }}}} }}} makes {{{ COST CENTRE MODULE SRC %time %alloc final_rdr_env InteractiveEval compiler/main/InteractiveEval.hs:660:59-104 48.0 91.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler